2020-04-10 Caio Lima [LLInt] Add fast path for TypedArray access on LLInt 32-bits https://bugs.webkit.org/show_bug.cgi?id=210217 Reviewed by Yusuke Suzuki. This patch is adding fast path case for in-bound TypedArray access on 32-bits LLInt. Since instructions are the same for both architectures, we are refactoring this part of code to `LowLevelInterpreter.asm` and reusing it into `LowLevelInterpreter32_64.asm`. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2020-04-10 Commit Queue Unreviewed, reverting r259849 and r259851. https://bugs.webkit.org/show_bug.cgi?id=210328 Crash in LayoutTests (Requested by yusukesuzuki on #webkit). Reverted changesets: "[JSC] Use UnconditionalWriteBarrier in Baseline effectively to reduce code size" https://bugs.webkit.org/show_bug.cgi?id=209395 https://trac.webkit.org/changeset/259849 "Unreviewed, fix typo in comment" https://bugs.webkit.org/show_bug.cgi?id=209395 https://trac.webkit.org/changeset/259851 2020-04-10 Yusuke Suzuki Unreviewed, fix typo in comment https://bugs.webkit.org/show_bug.cgi?id=209395 * jit/JITPropertyAccess.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_put_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_put_by_id): 2020-04-09 Yusuke Suzuki [JSC] Use UnconditionalWriteBarrier in Baseline effectively to reduce code size https://bugs.webkit.org/show_bug.cgi?id=209395 Reviewed by Tadeu Zagallo. In put/delete we always need to emit write-barrier if the base is a cell since IC can write things (writing new StructureID etc.). We should use emitWriteBarrier with UnconditionalWriteBarrier to remove unnecessary branch. * jit/JITPropertyAccess.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_put_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_put_by_id): 2020-04-09 Mark Lam Fix bad tests in testmasm's testCagePreservesPACFailureBit(). https://bugs.webkit.org/show_bug.cgi?id=210314 Reviewed by Yusuke Suzuki. Some of these tests will crash when validated untagging is enabled. * assembler/testmasm.cpp: (JSC::testCagePreservesPACFailureBit): 2020-04-08 Darin Adler [Cocoa] Simplify NSArray, NSDictionary, and NSNumber idioms throughout WebKit https://bugs.webkit.org/show_bug.cgi?id=210138 Reviewed by Alex Christensen. * API/JSValue.mm: (valueToObjectWithoutCopy): Use @(). (valueToNumber): Ditto. * API/tests/testapi.mm: (-[TestObject callback:]): Use @[], @(), and @{}. (-[TextXYZ click]): Ditto. (testObjectiveCAPIMain): Ditto. 2020-04-09 Devin Rousso Don't emit the rhs twice in `AssignResolveNode` https://bugs.webkit.org/show_bug.cgi?id=210312 Reviewed by Yusuke Suzuki. * bytecompiler/NodesCodegen.cpp: (JSC::AssignResolveNode::emitBytecode): 2020-04-09 Yusuke Suzuki [JSC] ModuleEnvironment do not have JSGlobalLexicalEnvironment as its upper scope https://bugs.webkit.org/show_bug.cgi?id=193347 Reviewed by Tadeu Zagallo. The upper scope of module scope should be global lexical environment instead of global object. This patch fixes it to allow modules to access global lexical environment's variables. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::notifyLexicalBindingUpdate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * runtime/JSModuleEnvironment.h: * runtime/JSModuleRecord.cpp: (JSC::JSModuleRecord::instantiateDeclarations): 2020-04-09 Alexey Shvayka ProxyObject::defineOwnProperty() should conditionally throw on falsy trap result https://bugs.webkit.org/show_bug.cgi?id=210267 Reviewed by Ross Kirsling. This change adds conditional TypeError for falsy trap result [1], like there is in ProxyObject::performPut(), aligning JSC with V8 and SpiderMonkey. Also replaces throwVMTypeError() calls which results are unused with throwTypeError(). [1]: https://tc39.es/ecma262/#sec-definepropertyorthrow (step 4) * runtime/ProxyObject.cpp: (JSC::ProxyObject::performDefineOwnProperty) 2020-04-09 Devin Rousso Web Inspector: Debugger: debug hooks should also be emitted for the first sub-expression in a comma expression https://bugs.webkit.org/show_bug.cgi?id=210253 Reviewed by Joseph Pecoraro. * bytecompiler/NodesCodegen.cpp: (JSC::CommaNode::emitBytecode): * parser/Parser.cpp: (JSC::Parser::parseVariableDeclarationList): (JSC::Parser::parseExpression): We should emit debug hooks and record pause locations for the first sub-expression in comma expressions, as the comma expression is not always standalone (e.g. `true && (a(), b())`). * bytecompiler/BytecodeGenerator.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitDebugHook): Save the `JSTextPosition` and `DebugHookType` of the last debug hook, using them to prevent any additional debug hooks from being emitted if they have the same `JSTextPosition` and `DebugHookType`. This prevents the debugger from pausing twice at the beginning of an expression statement (e.g. `|a(), b();`). 2020-04-09 Saam Barati We can still cache delete in strict mode as long as the property is not "non-configurable" https://bugs.webkit.org/show_bug.cgi?id=210148 Reviewed by Tadeu Zagallo. We were incorrectly not inline caching all delete misses in strict mode. We only must to not cache deletes on non-configurable properties in strict mode, as that should throw a runtime error. Delete misses can still be cached in strict mode without any issues. This is a 4x speedup on the microbenchmark. * jit/Repatch.cpp: (JSC::tryCacheDeleteBy): 2020-04-09 Sergio Villar Senin [Wasm] Build fix for non-unified builds https://bugs.webkit.org/show_bug.cgi?id=210277 Reviewed by Yusuke Suzuki. * wasm/WasmPlan.cpp: Added missing includes. * wasm/WasmPlan.h: Forward declare CodeBlock. 2020-04-09 Alexey Shvayka getOwnPropertyDescriptor() is incorrect with Proxy of exotic object https://bugs.webkit.org/show_bug.cgi?id=200560 Reviewed by Yusuke Suzuki. PropertyAttribute::CustomValue path in JSObject::getOwnPropertyDescriptor() needs to perform getDirect() on correct target. A correct target may be different since getOwnPropertySlot() may return not *own* property. This change removes a hack that was covering only JSProxy case and invokes getDirect() on slotBase(), ensuring ProxyObject instances with exotic targets return correct descriptors and aligning JSC with V8 and SpiderMonkey. getDirect() can be safely called on slotBase(): if getOwnPropertySlot() result is returned from JS code of ProxyObject's trap, it will never be a PropertyAttribute::CustomValue. This patch also moves setCustomDescriptor() down below to avoid mutating a descriptor when returning `false`. * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyDescriptor): 2020-04-09 Angelos Oikonomopoulos Fix CLOOP build https://bugs.webkit.org/show_bug.cgi?id=207119 Reviewed by Aakash Jain. * CMakeLists.txt: 2020-04-09 Mark Lam Implement a more efficient tagCFunction() tool. https://bugs.webkit.org/show_bug.cgi?id=210254 Reviewed by Keith Miller. Putting tagCFunction() to use. * b3/B3LowerMacros.cpp: * b3/B3LowerMacrosAfterOptimizations.cpp: * b3/B3MathExtras.cpp: * b3/B3ReduceLoopStrength.cpp: (JSC::B3::ReduceLoopStrength::reduceByteCopyLoopsToMemcpy): * b3/B3ReduceStrength.cpp: * b3/testb3_5.cpp: (testCallSimple): (testCallRare): (testCallRareLive): (testCallSimplePure): (testCallFunctionWithHellaArguments): (testCallFunctionWithHellaArguments2): (testCallFunctionWithHellaArguments3): (testCallSimpleDouble): (testCallSimpleFloat): (testCallFunctionWithHellaDoubleArguments): (testCallFunctionWithHellaFloatArguments): (testLinearScanWithCalleeOnStack): * b3/testb3_6.cpp: (testInterpreter): * b3/testb3_7.cpp: (testLICMPure): (testLICMPureSideExits): (testLICMPureWritesPinned): (testLICMPureWrites): (testLICMReadsLocalState): (testLICMReadsPinned): (testLICMReads): (testLICMPureNotBackwardsDominant): (testLICMPureFoiledByChild): (testLICMPureNotBackwardsDominantFoiledByChild): (testLICMExitsSideways): (testLICMWritesLocalState): (testLICMWrites): (testLICMFence): (testLICMWritesPinned): (testLICMControlDependent): (testLICMControlDependentNotBackwardsDominant): (testLICMControlDependentSideExits): (testLICMReadsPinnedWritesPinned): (testLICMReadsWritesDifferentHeaps): (testLICMReadsWritesOverlappingHeaps): (testLICMDefaultCall): (testShuffleDoesntTrashCalleeSaves): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::emitRestoreArguments): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::handleExitCounts): (JSC::DFG::osrWriteBarrier): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::callExceptionFuzz): * jit/CCallHelpers.cpp: (JSC::CCallHelpers::ensureShadowChickenPacket): * jit/JITOperations.cpp: * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::slowPathFor): (JSC::nativeForGenerator): (JSC::boundFunctionCallGenerator): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addTableGet): (JSC::Wasm::B3IRGenerator::addTableSet): (JSC::Wasm::B3IRGenerator::addRefFunc): (JSC::Wasm::B3IRGenerator::addTableSize): (JSC::Wasm::B3IRGenerator::addTableGrow): (JSC::Wasm::B3IRGenerator::addTableFill): (JSC::Wasm::B3IRGenerator::addGrowMemory): (JSC::Wasm::B3IRGenerator::setGlobal): (JSC::Wasm::B3IRGenerator::emitWriteBarrierForJSWrapper): (JSC::Wasm::B3IRGenerator::addOp): (JSC::Wasm::B3IRGenerator::addOp): * wasm/WasmThunks.cpp: (JSC::Wasm::triggerOMGEntryTierUpThunkGenerator): 2020-04-08 Devin Rousso Web Inspector: Debugger: treat comma sub-expressions as separate statements https://bugs.webkit.org/show_bug.cgi?id=209998 Reviewed by Joseph Pecoraro. Minifiers sometimes use `,` instead of `;` as a way of compressing multiple statements into a single statement (e.g. inside an `if` conditional). This makes stepping through minified code much less useful, as our current stepping logic is based on expressions (not including step in or step out). In most cases, we do actually want to treat each sub-expression in a comma expression as a statement so as to emulate the behaviour as if there were `;` instead. * bytecompiler/NodesCodegen.cpp: (JSC::CommaNode::emitBytecode): * parser/Parser.cpp: (JSC::Parser::parseVariableDeclarationList): (Parser::parseExpression): Shift the location of subsequent sub-expressions to be after the comma. Add breakpoint pause locations for each subsequent sub-expression. 2020-04-08 Ross Kirsling Remove ENABLE_INTL define https://bugs.webkit.org/show_bug.cgi?id=210164 Reviewed by Darin Adler. * Scripts/generateIntlCanonicalizeLanguage.py: * builtins/DatePrototype.js: * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToLocaleString): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/IntlCollator.cpp: * runtime/IntlCollator.h: * runtime/IntlCollatorConstructor.cpp: * runtime/IntlCollatorConstructor.h: * runtime/IntlCollatorPrototype.cpp: * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormat.cpp: * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatConstructor.cpp: * runtime/IntlDateTimeFormatConstructor.h: * runtime/IntlDateTimeFormatPrototype.cpp: * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormat.cpp: * runtime/IntlNumberFormat.h: * runtime/IntlNumberFormatConstructor.cpp: * runtime/IntlNumberFormatConstructor.h: * runtime/IntlNumberFormatPrototype.cpp: * runtime/IntlNumberFormatPrototype.h: * runtime/IntlObject.cpp: * runtime/IntlObject.h: * runtime/IntlObjectInlines.h: * runtime/IntlPluralRules.cpp: * runtime/IntlPluralRules.h: * runtime/IntlPluralRulesConstructor.cpp: * runtime/IntlPluralRulesConstructor.h: * runtime/IntlPluralRulesPrototype.cpp: * runtime/IntlPluralRulesPrototype.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::defaultCollator const): (JSC::JSGlobalObject::pluralRulesStructure): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncDateTimeFormat): * runtime/NumberPrototype.cpp: (JSC::numberProtoFuncToLocaleString): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncLocaleCompare): (JSC::stringProtoFuncToLocaleUpperCase): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2020-04-08 Daniel Bates Track editable elements on screen https://bugs.webkit.org/show_bug.cgi?id=209888 Reviewed by Simon Fraser. Add feature define to track editable elements on screen (enabled by default on iOS and iOS Simulator). * Configurations/FeatureDefines.xcconfig: 2020-04-08 Yusuke Suzuki [JSC] Threading JSGlobalObject in RegExp::match properly https://bugs.webkit.org/show_bug.cgi?id=210174 Reviewed by Saam Barati. We thread JSGlobalObject* properly in RegExp::match instead of accessing VM::topCallFrame, which is too hacky. * runtime/RegExp.cpp: (JSC::RegExp::match): (JSC::RegExp::matchConcurrently): * runtime/RegExp.h: * runtime/RegExpGlobalData.h: * runtime/RegExpGlobalDataInlines.h: (JSC::RegExpGlobalData::performMatch): * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * runtime/RegExpMatchesArray.h: (JSC::createRegExpMatchesArray): * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::matchInline): (JSC::collectMatches): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncSearchFast): (JSC::genericSplit): (JSC::regExpProtoFuncSplitFast): * runtime/StringPrototype.cpp: (JSC::removeUsingRegExpSearch): (JSC::replaceUsingRegExpSearch): * testRegExp.cpp: (testOneRegExp): (runFromFiles): 2020-04-08 Devin Rousso Web Inspector: Storage: cannot clear out multiple or all local storage entries https://bugs.webkit.org/show_bug.cgi?id=209867 Reviewed by Timothy Hatcher. * inspector/protocol/DOMStorage.json: Add a `clearDOMStorageItems` command instead of calling `removeDOMStorageItem` for each key. 2020-04-08 Yusuke Suzuki [JSC] MultiDeleteByOffset should tell correct result AbstractValue in AI https://bugs.webkit.org/show_bug.cgi?id=210175 Reviewed by Saam Barati. Since the result value of MultiDeleteByOffset should be used, AI should set boolean AbstractValue as a result of MultiDeleteByOffset. We also add MultiDeleteByOffset to DFGStoreBarrierInsertionPhase since it can write StructureID: this means that write-barrier is necessary. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGStoreBarrierInsertionPhase.cpp: 2020-04-08 Angelos Oikonomopoulos Enable offlineasm debug annotations for GCC https://bugs.webkit.org/show_bug.cgi?id=207119 Reviewed by Darin Adler. This simply reuses the existing code that generates debug annotations, adding two workarounds for limitations in GCC and GDB. First, the .file directives that offlineasm inserts in inline asm use file slots that conflict with those in the compilation unit that includes LLIntAssembly.h (specifically, LowLevelInterpreter.cpp). Clang's built-in assembler will transparently fix that for us, but for GCC we need to post-process the generated assembler. Unfortunately, cmake doesn't allow us to introduce a compiler wrapper for a single source file, so we need to create a separate target for it. This wrapping only happens when building with GCC and the user has explicitly requested debug information, either by selecting a Debug/RelWithDebInfo build or setting GCC_OFFLINEASM_SOURCE_MAP. Second, GDB will only look at the line table for a compilation unit if it can first resolve the address to one of the known symbols in the file. Introduce marker symbols to work around this bug. * CMakeLists.txt: 2020-04-08 Truitt Savell Unreviewed, reverting r259708. Broke the iOS device Build Reverted changeset: "Enable the use of XCBuild by default in Apple builds" https://bugs.webkit.org/show_bug.cgi?id=209890 https://trac.webkit.org/changeset/259708 2020-04-08 Guillaume Emont [JSC][32-bits] Build failure after r259676 (Not using strict mode within ClassDeclaration statement) https://bugs.webkit.org/show_bug.cgi?id=210176 Reviewed by Aakash Jain. Fixed 32-bit paths to match changes in r259676. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileDeleteById): (JSC::DFG::SpeculativeJIT::compileDeleteByVal): * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEval): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_put_by_id): 2020-04-08 Tim Horton Rearrange and simplify some JSC feature flags https://bugs.webkit.org/show_bug.cgi?id=210152 Reviewed by Saam Barati. * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: (Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget): * jit/ExecutableAllocator.cpp: (JSC::isJITEnabled): (JSC::ExecutableAllocator::setJITEnabled): * runtime/Options.cpp: (JSC::overrideDefaults): 2020-04-08 Keith Rollin Enable the use of XCBuild by default in Apple builds https://bugs.webkit.org/show_bug.cgi?id=209890 Reviewed by Darin Adler. Switch from the "legacy" Xcode build system to the "new" build system (also known as "XCBuild"). Switching to the new system speeds up builds by a small percentage, better validates projects for build-related issues (such as dependency cycles), lets WebKit benefit from future improvements in XCBuild such as those coming from the underlying llbuild open source project, and prepares us for any other tools built for this new ecosystem. Specific changes: - Remove Xcode project and workspace settings that selected the Build system, allowing the default to take hold (which is currently the New build system). - Updated webkitdirs.pm with a terser check for Xcode version. - Update build-webkit and Makefile.shared to be explicit when using the old build system (no longer treat it as a default or fall-back configuration). - Update various xcconfig files similarly to treat the default as using the new build system. - Update various post-processing build steps to check for Xcode 11.4 and to no longer treat the default as using the old build system. * Configurations/JavaScriptCore.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: 2020-04-07 Yusuke Suzuki [JSC] Collect-continuously thread should take m_collectContinuouslyLock while it is waking up concurrent collector thread https://bugs.webkit.org/show_bug.cgi?id=210163 Reviewed by Saam Barati. Collect-Continuously thread has fancy race issue. In Heap::preventCollection, we first take m_collectContinuouslyLock to ensure collect-continuously thread is not working, and then we ensure collector thread is stopped by using waitForCollector. However our collect-continuously thread is implemented like this. while (!m_shouldStopCollectingContinuously) { { // (A) LockHolder locker(*m_threadLock); if (m_requests.isEmpty()) { m_requests.append(WTF::nullopt); m_lastGrantedTicket++; m_threadCondition->notifyOne(locker); // (B) WAKING UP concurrent collector thread. } } { LockHolder locker(m_collectContinuouslyLock); ... while (!hasElapsed(timeToWakeUp) && !m_shouldStopCollectingContinuously) m_collectContinuouslyCondition.waitUntil(m_collectContinuouslyLock, timeToWakeUp); } } Even if m_collectContinuouslyLock is taken, collect-continuously thread is still able to wake up concurrent collector thread since (B)'s code is not guarded by m_collectContinuouslyLock. The following sequence can happen, 1. The main thread calls Heap::preventCollection to ensure all collection is stopped. 2. The collect-continuously thread is at (A) point. 3. The main thread takes m_collectContinuouslyLock. This is OK. 4. The main thread calls waitForCollector to ensure that concurrent collector thread is stopped. 5. The collect-continuously thread executes (B). It is allowed since this is not guarded by m_collectContinuouslyLock. So, concurrent collector starts working. 6. While the main thread called Heap::preventCollection, concurrent collector starts collection! We should guard (A)'s block with m_collectContinuouslyLock too. * heap/Heap.cpp: (JSC::Heap::notifyIsSafeToCollect): 2020-04-07 Saam Barati Delete ICs can't cache dictionaries https://bugs.webkit.org/show_bug.cgi?id=210147 Reviewed by Tadeu Zagallo. We were happily caching delete IC cases on a dictionary object. This is clearly wrong, as we might cache a miss on a dictionary on a property "P", even though we might add "P" to the structure without transitioning it. * jit/Repatch.cpp: (JSC::tryCacheDeleteBy): 2020-04-07 Tadeu Zagallo Not using strict mode within ClassDeclaration statement https://bugs.webkit.org/show_bug.cgi?id=205578 Reviewed by Yusuke Suzuki. We correctly set strict mode when parsing classes, but we did not set it when emitting bytecode. However, that means that we can now have a subset of a code block's bytecode that must be run in strict mode, even when the code block itself is not strict. As it turns out, there are only ten opcodes that need to be aware of strictness, so an extra `mode` operand was added to these opcodes. The mode then needs to be propagated through baseline, DFG and FTL. * API/APICallbackFunction.h: (JSC::APICallbackFunction::call): * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::call): * API/JSContextRef.cpp: (JSContextGetGlobalObject): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/BytecodeDumper.cpp: * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::run): * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType const): (JSC::CodeBlock::finishCreation): * bytecode/CodeBlock.h: (JSC::CodeBlock::isConstructor const): (JSC::CodeBlock::isKnownCell): * bytecode/ExecutableInfo.h: (JSC::ExecutableInfo::ExecutableInfo): (JSC::ExecutableInfo::usesEval const): * bytecode/Fits.h: * bytecode/InlineCallFrame.cpp: (JSC::InlineCallFrame::dumpInContext const): * bytecode/InlineCallFrame.h: (JSC::InlineCallFrame::isInStrictContext const): * bytecode/PutByIdFlags.cpp: (WTF::printInternal): * bytecode/PutByIdFlags.h: (JSC::PutByIdFlags::create): (JSC::PutByIdFlags::createDirect): (JSC::PutByIdFlags::isDirect const): (JSC::PutByIdFlags::ecmaMode const): (JSC::PutByIdFlags::PutByIdFlags): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::isConstructor const): * bytecode/UnlinkedCodeBlockGenerator.h: (JSC::UnlinkedCodeBlockGenerator::needsClassFieldInitializer const): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitGetFromScope): (JSC::BytecodeGenerator::emitPutToScope): (JSC::BytecodeGenerator::emitPutById): (JSC::BytecodeGenerator::emitDirectPutById): (JSC::BytecodeGenerator::emitDeleteById): (JSC::BytecodeGenerator::emitPutByVal): (JSC::BytecodeGenerator::emitDirectPutByVal): (JSC::BytecodeGenerator::emitDeleteByVal): (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitPushFunctionNameScope): (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded): (JSC::BytecodeGenerator::emitToThis): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::ecmaMode const): (JSC::StrictModeScope::StrictModeScope): * bytecompiler/NodesCodegen.cpp: (JSC::AssignResolveNode::emitBytecode): (JSC::EmptyLetExpression::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::ClassExprNode::emitBytecode): (JSC::BindingNode::bindValue const): (JSC::AssignmentElementNode::bindValue const): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::thisValue const): (JSC::DebuggerCallFrame::evaluateWithScopeExtension): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::isToThisAnIdentity): (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleDOMJITCall): (JSC::DFG::ByteCodeParser::handleDeleteById): (JSC::DFG::ByteCodeParser::emitPutById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupToThis): * dfg/DFGGraph.h: (JSC::DFG::Graph::globalThisObjectFor): * dfg/DFGNode.h: (JSC::DFG::Node::hasECMAMode): (JSC::DFG::Node::ecmaMode): * dfg/DFGOpInfo.h: (JSC::DFG::OpInfo::OpInfo): * dfg/DFGOperations.cpp: * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithString): (JSC::DFG::SpeculativeJIT::compilePutByValForCellWithSymbol): (JSC::DFG::SpeculativeJIT::compilePutDynamicVar): (JSC::DFG::SpeculativeJIT::compilePutByIdFlush): (JSC::DFG::SpeculativeJIT::compilePutById): (JSC::DFG::SpeculativeJIT::compilePutByIdDirect): (JSC::DFG::SpeculativeJIT::compilePutByIdWithThis): (JSC::DFG::SpeculativeJIT::compileToThis): (JSC::DFG::SpeculativeJIT::cachedPutById): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileDeleteById): (JSC::DFG::SpeculativeJIT::compileDeleteByVal): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileToThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutById): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteById): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::internalConstructorName): * interpreter/Interpreter.cpp: (JSC::eval): (JSC::Interpreter::execute): * interpreter/Interpreter.h: * jit/AssemblyHelpers.h: * jit/JITCall.cpp: (JSC::JIT::compileCallEval): * jit/JITInlineCacheGenerator.cpp: (JSC::JITPutByIdGenerator::slowPathFunction): * jit/JITInlineCacheGenerator.h: (JSC::JITPutByIdGenerator::JITPutByIdGenerator): * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::emitJumpSlowCaseIfNotJSCell): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emitSlow_op_del_by_id): (JSC::JIT::emitSlow_op_del_by_val): (JSC::JIT::emit_op_put_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitSlow_op_put_by_val): * jit/Repatch.cpp: (JSC::tryCacheDeleteBy): (JSC::repatchDeleteBy): * jit/Repatch.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::commonCallEval): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToString): (JSC::arrayProtoFuncToLocaleString): (JSC::arrayProtoFuncJoin): (JSC::arrayProtoFuncPop): (JSC::arrayProtoFuncPush): (JSC::arrayProtoFuncReverse): (JSC::arrayProtoFuncShift): (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): (JSC::arrayProtoFuncUnShift): (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): * runtime/CachedTypes.cpp: (JSC::CachedCodeBlock::usesEval const): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::CachedCodeBlock::encode): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::getOwnPropertySlot): (JSC::ClonedArguments::materializeSpecials): * runtime/CodeCache.cpp: (JSC::generateUnlinkedCodeBlockImpl): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPathsInlines.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/Completion.cpp: (JSC::evaluate): * runtime/DirectEvalExecutable.cpp: (JSC::DirectEvalExecutable::create): * runtime/DirectEvalExecutable.h: * runtime/ECMAMode.cpp: Copied from Source/JavaScriptCore/bytecode/PutByIdFlags.cpp. (JSC::ECMAMode::dump const): * runtime/ECMAMode.h: Copied from Source/JavaScriptCore/bytecode/PutByIdFlags.h. (JSC::ECMAMode::fromByte): (JSC::ECMAMode::strict): (JSC::ECMAMode::sloppy): (JSC::ECMAMode::isStrict const): (JSC::ECMAMode::value const): (JSC::ECMAMode::ECMAMode): * runtime/EvalExecutable.h: (JSC::EvalExecutable::executableInfo const): * runtime/FunctionExecutable.h: * runtime/GetPutInfo.cpp: (JSC::GetPutInfo::dump const): * runtime/GetPutInfo.h: (JSC::GetPutInfo::GetPutInfo): (JSC::GetPutInfo::ecmaMode const): * runtime/GetterSetter.cpp: (JSC::callSetter): * runtime/IndirectEvalExecutable.cpp: (JSC::IndirectEvalExecutable::create): (JSC::IndirectEvalExecutable::IndirectEvalExecutable): * runtime/IndirectEvalExecutable.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::toThisSlowCase const): (JSC::JSValue::putToPrimitive): * runtime/JSCJSValue.h: * runtime/JSCell.cpp: (JSC::JSCell::toThis): * runtime/JSFunction.cpp: (JSC::JSFunction::selectStructureForNewFuncExp): (JSC::JSFunction::callerGetter): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncEval): (JSC::globalFuncProtoGetter): (JSC::globalFuncProtoSetter): * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::setPrototypeWithCycleCheck): * runtime/JSScope.cpp: (JSC::JSScope::toThis): * runtime/JSString.cpp: (JSC::JSString::toThis): * runtime/LiteralParser.cpp: (JSC::LiteralParser::parse): * runtime/ModuleProgramExecutable.h: * runtime/NullSetterFunction.cpp: (JSC::GetCallerStrictnessFunctor::operator() const): (JSC::NullSetterFunctionInternal::callReturnUndefined): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncValueOf): (JSC::objectProtoFuncHasOwnProperty): (JSC::objectProtoFuncIsPrototypeOf): (JSC::objectProtoFuncDefineGetter): (JSC::objectProtoFuncDefineSetter): (JSC::objectProtoFuncLookupGetter): (JSC::objectProtoFuncLookupSetter): (JSC::objectProtoFuncPropertyIsEnumerable): (JSC::objectProtoFuncToLocaleString): (JSC::objectProtoFuncToString): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/ProgramExecutable.h: * runtime/ProxyObject.cpp: (JSC::performProxyCall): * runtime/ScriptExecutable.h: (JSC::ScriptExecutable::isArrowFunctionContext const): (JSC::ScriptExecutable::isInStrictContext const): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayEntry::put): 2020-04-07 Saam Barati RAMification should have a way of gathering vmmaps for each test at the end of each run https://bugs.webkit.org/show_bug.cgi?id=210060 Reviewed by Yusuke Suzuki. * jsc.cpp: (main): 2020-04-07 Yusuke Suzuki [JSC] ScopedArgumentsTable should handle OOM in tolerant manner https://bugs.webkit.org/show_bug.cgi?id=210126 Reviewed by Mark Lam. This patch makes ScopedArgumentsTable allocations OOM tolerant to throw OOM error when allocation fails. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * runtime/CachedTypes.cpp: (JSC::CachedScopedArgumentsTable::decode const): * runtime/ScopedArguments.cpp: (JSC::ScopedArguments::unmapArgument): * runtime/ScopedArgumentsTable.cpp: (JSC::ScopedArgumentsTable::tryClone): (JSC::ScopedArgumentsTable::trySetLength): (JSC::ScopedArgumentsTable::trySet): (JSC::ScopedArgumentsTable::clone): Deleted. (JSC::ScopedArgumentsTable::setLength): Deleted. (JSC::ScopedArgumentsTable::set): Deleted. * runtime/ScopedArgumentsTable.h: * runtime/SymbolTable.h: 2020-04-07 Yusuke Suzuki [JSC] JSWrapperObject should use JSInternalFieldObjectImpl https://bugs.webkit.org/show_bug.cgi?id=210019 Reviewed by Mark Lam. JSWrapperObject's mechanism can be basically implemented by using JSInternalFieldObjectImpl. We should leverage JSInternalFieldObjectImpl to implement JSWrapperObject since it can pave the way to implementing Object-Allocation-Sinking and faster access to value etc. in DFG without duplicating code. We also noticed that we are storing classInfo to JSWrapperObject when allocating StringObject in DFG and FTL while JSWrapperObject is no longer inheriting JSDestructibleObject! But it turned out that this is safe since the subsequent JSWrapperObject::internalValue setting can overwrite it. We remove this wrong store. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewStringObject): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject): Deleted. * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject): (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateDestructibleObject): Deleted. * runtime/BigIntObject.h: * runtime/BooleanObject.h: * runtime/JSDestructibleObject.h: (JSC::JSDestructibleObject::classInfo const): (JSC::JSDestructibleObject::classInfoOffset): Deleted. * runtime/JSWrapperObject.cpp: (JSC::JSWrapperObject::visitChildren): * runtime/JSWrapperObject.h: (JSC::JSWrapperObject::internalValueOffset): (JSC::JSWrapperObject::internalValue const): (JSC::JSWrapperObject::setInternalValue): (JSC::JSWrapperObject::createStructure): Deleted. * runtime/NumberObject.h: * runtime/StringObject.h: * runtime/SymbolObject.h: 2020-04-07 Yusuke Suzuki [JSC] Inlined IC should get right JSGlobalObject https://bugs.webkit.org/show_bug.cgi?id=210092 Reviewed by Tadeu Zagallo. In DFG / FTL, CodeBlock in AccessCase is the DFG / FTL CodeBlock which includes all the inlined CodeBlocks. If inlining happens with CodeBlock which has different JSGlobalObject, CodeBlock->globalObject() is different to the actual lexical JSGlobalObject of the IC. So basically, we should not rely on codeBlock->globalObject() in IC. This patch passes the correct lexical JSGlobalObject to IC to use. We do not retain this JSGlobalObject. Since this is lexical JSGlobalObject of that IC, the owner CodeBlock of this IC should already retain it (even if this JSGlobalObject is one of inlined CodeBlock since the owner CodeBlock retains inlined lower-tier CodeBlocks). * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): * bytecode/StructureStubInfo.h: * jit/Repatch.cpp: (JSC::tryCacheGetBy): (JSC::tryCacheArrayGetByVal): (JSC::tryCachePutByID): (JSC::tryCacheDeleteBy): (JSC::tryCacheInByID): (JSC::tryCacheInstanceOf): * tools/JSDollarVM.cpp: 2020-04-07 Yusuke Suzuki [JSC] $.evalScript should check exception when accessing "global" https://bugs.webkit.org/show_bug.cgi?id=210114 Reviewed by Keith Miller. $.evalScript should check exception after "global" property access since it can throw an error if it is an accessor. * jsc.cpp: (functionDollarEvalScript): 2020-04-06 Devin Rousso Web Inspector: `console.log(...)` appear as `CONSOLE LOG LOG` in the system console https://bugs.webkit.org/show_bug.cgi?id=210083 Reviewed by Timothy Hatcher. * runtime/ConsoleClient.cpp: (JSC::appendMessagePrefix): 2020-04-06 Mark Lam REGRESSION: 68000 JSC tests failing. https://bugs.webkit.org/show_bug.cgi?id=210078 Reviewed by Yusuke Suzuki. The missing exception check is in jsc shell's GlobalObject::finishCreation(). Since this is just a debugging tool, and this exception will never be thrown in practice, I've placated the validator by RELEASE_ASSERT'ing that the exception will never be thrown. * jsc.cpp: 2020-04-06 Ross Kirsling Update minimum ICU version to 60.2 https://bugs.webkit.org/show_bug.cgi?id=209694 Reviewed by Darin Adler. * icu/LICENSE: Deleted. * icu/README: Deleted. Remove leftover files following r219155. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::UFieldPositionIteratorDeleter::operator() const): (JSC::IntlDateTimeFormat::partTypeString): (JSC::IntlDateTimeFormat::formatToParts): * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::partTypeString): (JSC::IntlNumberFormat::formatToParts): * runtime/IntlNumberFormat.h: * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): (JSC::IntlNumberFormatPrototypeFuncFormatToParts): * runtime/IntlPluralRules.cpp: (JSC::IntlPluralRules::resolvedOptions): (JSC::IntlPluralRules::select): * runtime/IntlPluralRules.h: * runtime/JSGlobalObjectFunctions.cpp: (JSC::decode): Remove obsoleted compile-time version checks. 2020-04-06 Fujii Hironori [Clang 10] Fix -Wimplicit-int-float-conversion compilation warnings in JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=210038 Reviewed by Darin Adler. Clang 10 reports a compilation warning in JavaScriptCore: > ..\..\Source\JavaScriptCore\bytecode/CodeBlock.cpp(3002,24): warning: implicit conversion from 'unsigned long long' to 'double' changes value from 18446744073709551615 to 18446744073709551616 [-Wimplicit-int-float-conversion] > if (doubleResult > std::numeric_limits::max()) > ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use a template variable maxPlusOne which was added by r259537 for the purpose. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::predictedMachineCodeSize): Replaced '>' with '>=', and std::numeric_limits::max() with maxPlusOne. 2020-04-06 Rick Waldron and Alexey Shvayka Remove unnecessary Test262 harness file and implement $262.IsHTMLDDA https://bugs.webkit.org/show_bug.cgi?id=187526 Reviewed by Darin Adler. Test262 harness requires [1] $262.IsHTMLDDA to be an object with [[IsHTMLDDA]] slot [2], much like `document.all`. It is used in a few tests to make sure that runtimes strictly compare values with `null` and `undefined`. With this change, `makeMasquerader` returns callable masquerader to mimic `document.all` in the wild. In order to avoid `masqueradesAsUndefinedWatchpoint` being fired during initialization of JSC shell, $262.IsHTMLDDA is a getter. [1]: https://github.com/tc39/test262/blob/master/INTERPRETING.md#host-defined-functions [2]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot * jsc.cpp: (functionMakeMasquerader): (functionCallMasquerader): (JSC::Masquerader::Masquerader): Deleted. (JSC::Masquerader::subspaceFor): Deleted. (JSC::Masquerader::create): Deleted. (JSC::Masquerader::createStructure): Deleted. * runtime/JSObject.h: 2020-04-06 Justin Michaud Allow deleteById to be cached in the DFG https://bugs.webkit.org/show_bug.cgi?id=208664 Reviewed by Saam Barati. When we see that the deleteById inline cache only saw one structure, we inline it into the DFG. This involves creating a new node, FilterDeleteByStatus, and then turning these DeleteById nodes into a FilterDeleteByStatus, CheckStructure, PutByOffset, then PutStructure (or just a CheckStructure in the case of a miss). The logic for pessimising this optimization is the same as for PutById, giving inlined functions the opportunity to use only the DFG profiling information, while everything else uses the DFG+Baseline information. This also adds a MultiDeleteByOffset node, for the case when there are multiple structures seen by the delete. If all of the cases are the same kind of miss, then we only emit a CheckStructure and constant. Finally, if we see a delete by val with a single identifier, we inline that too. This patch removes a dead code path from deleteProperty that checks if we need to nuke the object's butterfly. This also fixes a bug where we were checking the neutering status of typed arrays for named properties when we should only check for indexed properties. The behavior of this now matches for all tiers including when cached. The benchmark shows a 2x improvement on polyvariant-delete-property, and a 50% improvement on delete-property-allocation-sinking. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::createDelete): (JSC::AccessCase::generateImpl): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::getICStatusMap): * bytecode/DeleteByIdVariant.cpp: Added. (JSC::DeleteByIdVariant::DeleteByIdVariant): (JSC::DeleteByIdVariant::~DeleteByIdVariant): (JSC::DeleteByIdVariant::operator=): (JSC::DeleteByIdVariant::attemptToMerge): (JSC::DeleteByIdVariant::writesStructures const): (JSC::DeleteByIdVariant::visitAggregate): (JSC::DeleteByIdVariant::markIfCheap): (JSC::DeleteByIdVariant::dump const): (JSC::DeleteByIdVariant::finalize): (JSC::DeleteByIdVariant::dumpInContext const): * bytecode/DeleteByIdVariant.h: Added. (JSC::DeleteByIdVariant::oldStructure const): (JSC::DeleteByIdVariant::newStructure const): (JSC::DeleteByIdVariant::result const): (JSC::DeleteByIdVariant::offset const): (JSC::DeleteByIdVariant::isPropertyUnset const): (JSC::DeleteByIdVariant::identifier const): (JSC::DeleteByIdVariant::overlaps): * bytecode/DeleteByStatus.cpp: Added. (JSC::DeleteByStatus::appendVariant): (JSC::DeleteByStatus::computeForBaseline): (JSC::DeleteByStatus::DeleteByStatus): (JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::DeleteByStatus::computeFor): (JSC::DeleteByStatus::slowVersion const): (JSC::DeleteByStatus::merge): (JSC::DeleteByStatus::filter): (JSC::DeleteByStatus::singleIdentifier const): (JSC::DeleteByStatus::visitAggregate): (JSC::DeleteByStatus::markIfCheap): (JSC::DeleteByStatus::finalize): (JSC::DeleteByStatus::dump const): * bytecode/DeleteByStatus.h: Added. * bytecode/ICStatusMap.h: * bytecode/RecordedStatuses.cpp: (JSC::RecordedStatuses::operator=): (JSC::RecordedStatuses::addDeleteByStatus): (JSC::RecordedStatuses::visitAggregate): (JSC::RecordedStatuses::markIfCheap): * bytecode/RecordedStatuses.h: (JSC::RecordedStatuses::forEachVector): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): (JSC::DFG::AbstractInterpreter::filterICStatus): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleDeleteById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): (JSC::DFG::ConstantFoldingPhase::emitDeleteByOffset): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: * dfg/DFGMayExit.cpp: * dfg/DFGNode.cpp: (JSC::DFG::MultiDeleteByOffsetData::writesStructures const): * dfg/DFGNode.h: (JSC::DFG::Node::hasMultiDeleteByOffsetData): (JSC::DFG::Node::multiDeleteByOffsetData): (JSC::DFG::Node::hasDeleteByStatus): (JSC::DFG::Node::deleteByStatus): * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * 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/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * dfg/DFGValidate.cpp: * dfg/DFGVarargsForwardingPhase.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileMultiDeleteByOffset): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::deleteProperty): * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::mayHaveIndexingHeader const): Deleted. (JSC::Structure::canCacheDeleteIC const): Deleted. 2020-04-06 Saam Barati Implement 1GB of executable memory on arm64 https://bugs.webkit.org/show_bug.cgi?id=208490 Reviewed by Keith Miller. This patch implements the 1GB executable memory space on arm64. To make this work, we implement jumps larger than +/-128MB to use jump islands. Jump islands work by splitting up the ~1GB region into 9 112MB chunks (1008 MB total). Each chunk is split into two: 96MB of executable region, and 16MB of jump island region. With this split, any jump inside a jump island region can get to the adjacent island (forwards or backwards) in a single +/-128MB jump. When linking a jump from A to B, where |A - B| > 128MB, we instead point the jump to an island, where this island has a potential series of jumps that finally lands at B. To allocate executable memory, use a MetaAllocator for each 96MB chunk. To allocate islands, we have a bit vector we use to track used and freed islands. We only grow this bit vector as islands are allocated, so it frequently remains empty or very small. The goal of this patch is to have minimal perf impact when not using islands, so the data structures are designed to only incur overhead when actually using islands. We expect the use of islands to be minimal. We use a red black tree to track all island locations. This allows us to deallocate all islands when an executable memory handle is freed. Typically, this red black tree is empty, so freeing an executable memory handle incurs no extra overhead. To make islands work for Wasm, we now have to link tier up code in two phases. Previously, we would just patch jumps concurrently to Wasm threads running after resetting the icache, knowing that we would be able to atomically update the jump instruction to point to the new destination. However, now when repatching these jumps in a world with jump islands, we might need to allocate islands depending on the jump location and its target. So we now allocate and collect the set of islands, then reset the icache, then atomically update the branch to point to the destination (or an island that jumps to the destination). One important implementation detail here is that for normal island repatching, if we have a jump from A to B, and it allocates a set if islands X, we usually can deallocate X when repatching A to go to B'. This is because the typical repatch scenario in JS happens when that code is not being executed. For Wasm though, those islands X might be running while we want to repatch A to go to B'. So instead of deallocating X, we just append to X in this scenario, and we free the new set X' when the code itself is freed. (This patch also fixes a bug in the Wasm LLInt to BBQ tier up that I spotted, where we would publish a LLInt callee's BBQ replacement before we finished linking the outgoing calls of the BBQ replacement.) This patch also removes the old "CodeProfiling" code that has been unused for a long time. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::b): (JSC::ARM64Assembler::bl): (JSC::ARM64Assembler::replaceWithJump): (JSC::ARM64Assembler::prepareForAtomicRelinkJumpConcurrently): (JSC::ARM64Assembler::prepareForAtomicRelinkCallConcurrently): (JSC::ARM64Assembler::computeJumpType): (JSC::ARM64Assembler::canEmitJump): (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::prepareForAtomicRepatchNearCallConcurrently): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): (JSC::LinkBuffer::linkCode): (JSC::LinkBuffer::allocate): (JSC::LinkBuffer::performFinalization): * assembler/LinkBuffer.h: (JSC::LinkBuffer::LinkBuffer): (JSC::LinkBuffer::setIsJumpIsland): * assembler/MacroAssemblerCodeRef.h: (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef): * jit/ExecutableAllocator.cpp: (JSC::initializeJITPageReservation): (JSC::ExecutableAllocator::initializeUnderlyingAllocator): (JSC::ExecutableAllocator::isValid const): (JSC::ExecutableAllocator::allocate): (JSC::ExecutableAllocator::getJumpIslandTo): (JSC::ExecutableAllocator::getJumpIslandToConcurrently): (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator): Deleted. * jit/ExecutableAllocator.h: (JSC::ExecutableAllocatorBase::allocate): * runtime/CommonSlowPaths.cpp: * runtime/Completion.cpp: (JSC::evaluate): * runtime/JSModuleLoader.cpp: (JSC::moduleLoaderParseModule): * runtime/OptionsList.h: * tools/CodeProfile.cpp: (JSC::truncateTrace): Deleted. (JSC::CodeProfile::sample): Deleted. (JSC::CodeProfile::report): Deleted. * tools/CodeProfile.h: (JSC::CodeProfile::CodeProfile): Deleted. (JSC::CodeProfile::parent): Deleted. (JSC::CodeProfile::addChild): Deleted. (): Deleted. (JSC::CodeProfile::CodeRecord::CodeRecord): Deleted. * tools/CodeProfiling.cpp: (JSC::setProfileTimer): Deleted. (JSC::profilingTimer): Deleted. (JSC::CodeProfiling::sample): Deleted. (JSC::CodeProfiling::notifyAllocator): Deleted. (JSC::CodeProfiling::getOwnerUIDForPC): Deleted. (JSC::CodeProfiling::begin): Deleted. (JSC::CodeProfiling::end): Deleted. * tools/CodeProfiling.h: (): Deleted. (JSC::CodeProfiling::CodeProfiling): Deleted. (JSC::CodeProfiling::~CodeProfiling): Deleted. (JSC::CodeProfiling::enabled): Deleted. (JSC::CodeProfiling::beVerbose): Deleted. (JSC::CodeProfiling::beVeryVerbose): Deleted. * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): * wasm/WasmCodeBlock.h: * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::work): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::updateCallSitesToCallUs): * wasm/WasmPlan.h: 2020-04-06 Yusuke Suzuki [JSC] Since ArrayBufferViewWatchpointAdaptor::add can fire watchpoints, DFG::Plan should check validity of CodeBlock after executing reallyAdd https://bugs.webkit.org/show_bug.cgi?id=210055 Reviewed by Keith Miller. Since ArrayBufferViewWatchpointAdaptor::add can fire watchpoints, it is possible that the DFG CodeBlock is already invalidated after executing DFG::Plan::reallyAdd. We should check CodeBlock's validity again and terminate DFG::Plan::finalizeWithoutNotifyingCallback with CompilationInvalidated if CodeBlock got invalidated. * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): 2020-04-06 Yusuke Suzuki [JSC] Put ensureStillAliveHere for Integer TypedArrays in GetByVal https://bugs.webkit.org/show_bug.cgi?id=210047 Reviewed by Mark Lam. While r258381 puts ensureStillAliveHere in FTL to keep base alive for float/double TypedArrays, we need to do the same thing for integer TypedArrays too. This patch places it. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): 2020-04-05 Gus Caplan and Ross Kirsling DLLLauncherMain print to console instead of opening window on fatal error https://bugs.webkit.org/show_bug.cgi?id=206537 Reviewed by Fujii Hironori. * shell/DLLLauncherMain.cpp: (fatalError): 2020-04-05 Ross Kirsling JSC shell shouldn't treat NUL as a terminator when printing a JS string https://bugs.webkit.org/show_bug.cgi?id=210037 Reviewed by Darin Adler. Since JS strings aren't null-terminated, it's probably a better experience to not stop printing when we see \0. That is, 'abc\0def' should be printed as `abcdef` and not `abc`. This patch updates our printing of evaluation results as well as the print / printErr / debug functions. * jsc.cpp: (printInternal): (functionDebug): (runInteractive): 2020-04-05 Yusuke Suzuki Putting "memory" back to ensureStillAliveHere https://bugs.webkit.org/show_bug.cgi?id=210028 Reviewed by Keith Miller. We put "memory" back to make ensureStillAliveHere compiler-barrier. * runtime/EnsureStillAliveHere.h: (JSC::ensureStillAliveHere): * runtime/JSCJSValue.h: (JSC::ensureStillAliveHere): 2020-04-05 Mark Lam ARM64 moveConditionallyDouble() for DoubleNotEqualAndOrdered is wrong. https://bugs.webkit.org/show_bug.cgi?id=210039 Reviewed by Yusuke Suzuki. For the scenario where the dest register is same as the then case register, there is one csel instruction that should be checking the overflow condition to test for unordered operands. Instead, we were testing for the not equal condition. This patch fixes it to check for the overflow condition. This bug was caught by testmasm. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare): 2020-04-05 David Kilzer Sort JavaScriptCore Xcode project file * JavaScriptCore.xcodeproj/project.pbxproj: Sort the project file to try to force buildbots to rebuild and resign JavaScriptCore.framework. Some bots are stuck with a codesign error after r259545. 2020-04-05 Keith Miller ensureStillAliveHere can take the value in any location https://bugs.webkit.org/show_bug.cgi?id=210028 Reviewed by Mark Lam. It shouldn't matter if the value is on the stack or in a register because we're not going to do anything with it. Also, there's no reason to clobber memory. * runtime/EnsureStillAliveHere.h: (JSC::ensureStillAliveHere): 2020-04-05 Zan Dobersek Unreviewed, adding missing header inclusions to get non-unified build building. * heap/HeapSnapshotBuilder.h: * tools/Integrity.h: 2020-04-05 Mark Lam Change s_entropyBitsShiftForStructurePointer to 48 bits. https://bugs.webkit.org/show_bug.cgi?id=210022 Reviewed by Keith Miller. This is ok because the top 16 bits of the 64-bit address is not used. We can fill out the top 16-bits of the encodedStructureBits with the lowest 16-bits of the StructureID (which includes the 7-bits of entropy). * runtime/StructureIDTable.h: 2020-04-05 Yusuke Suzuki [JSC] JSArrayIterator's size is wrong https://bugs.webkit.org/show_bug.cgi?id=210020 Reviewed by Mark Lam. Internal-size of JSArrayIterator should be 3, not 4. * runtime/JSArrayIterator.h: 2020-04-05 Mark Lam Rolling out r259545: causing CodeSigning error in jsc EWS bot. https://bugs.webkit.org/show_bug.cgi?id=210018 Not reviewed. * JavaScriptCore.xcodeproj/project.pbxproj: 2020-04-05 Mark Lam Add some structureID integrity checks to various runtime functions. https://bugs.webkit.org/show_bug.cgi?id=210015 Reviewed by Keith Miller. Specifically, implementations of toString(), toValue(), and a few others. I also moved the HeapCell version of ensureStillAliveHere() into the new EnsureStillAliveHere.h/cpp since it's useful for any pointers, not just HeapCells. This change is performance neutral on JetStream 2.0, Speedometer-2, and PLT5. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/HeapCell.cpp: (JSC::ensureStillAliveHere): Deleted. * heap/HeapCell.h: (JSC::ensureStillAliveHere): Deleted. * heap/SlotVisitor.cpp: (JSC::SlotVisitor::appendJSCellOrAuxiliary): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToString): * runtime/BigIntPrototype.cpp: (JSC::bigIntProtoFuncToStringImpl): (JSC::bigIntProtoFuncValueOf): * runtime/BooleanPrototype.cpp: (JSC::booleanProtoFuncToString): (JSC::booleanProtoFuncValueOf): * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): (JSC::formateDateInstance): (JSC::dateProtoFuncToISOString): (JSC::dateProtoFuncToPrimitiveSymbol): * runtime/EnsureStillAliveHere.cpp: Added. (JSC::ensureStillAliveHere): * runtime/EnsureStillAliveHere.h: Added. (JSC::ensureStillAliveHere): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::sanitizedToString): * runtime/ErrorPrototype.cpp: (JSC::errorProtoFuncToString): * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): * runtime/JSCell.cpp: (JSC::JSCell::toObjectSlow const): * runtime/NumberPrototype.cpp: (JSC::toThisNumber): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncValueOf): (JSC::objectProtoFuncToString): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncToString): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncToString): * runtime/StructureIDTable.h: (JSC::StructureIDTable::validate): (JSC::StructureIDTable::isValid): Deleted. * runtime/SymbolPrototype.cpp: (JSC::symbolProtoGetterDescription): (JSC::symbolProtoFuncToString): (JSC::symbolProtoFuncValueOf): * tools/Integrity.h: * tools/IntegrityInlines.h: (JSC::Integrity::auditStructureID): * wasm/js/WebAssemblyGlobalPrototype.cpp: (JSC::getGlobal): 2020-04-05 Alexey Shvayka Octal escapes should be max 3 digits and syntax errors in Unicode patterns https://bugs.webkit.org/show_bug.cgi?id=167067 Reviewed by Ross Kirsling. This patch: a) Adds SyntaxError for octal escapes in Unicode patterns, while preserving /\0/u being parsed as null character escape. Grammar: https://tc39.es/ecma262/#prod-CharacterEscape b) Limits consumeOctal() to 3 digits only, preventing it from consuming leading zeros. Grammar: https://tc39.es/ecma262/#prod-annexB-LegacyOctalEscapeSequence Both changes align JSC with V8 and SpiderMonkey. * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::consumeOctal): 2020-04-04 Keith Miller copy jsc CLI into JavaScriptCore.framework earlier https://bugs.webkit.org/show_bug.cgi?id=210018 Reviewed by Mark Lam. Some of our test scripts only copy the JavaScriptCore.framework into the test directory and try to run jsc from there. We should copy the jsc CLI ASAP so we don't need to build all the other test binaries unless we actually need them. * JavaScriptCore.xcodeproj/project.pbxproj: 2020-04-04 Alexey Shvayka '\u' should throw an early SyntaxError exception, but instead evaluates to 'u' https://bugs.webkit.org/show_bug.cgi?id=198790 Reviewed by Yusuke Suzuki. This change removes special-case for '\u', invoking parseUnicodeEscape() right away, aligning string literals with ES6 template literals. parseComplexEscape() method signature is greatly simplified, JSC is aligned with V8 and SpiderMonkey. Grammar: https://tc39.es/ecma262/#prod-UnicodeEscapeSequence (Hex4Digits or '{' is required, otherwise parsing fails) * parser/Lexer.cpp: (JSC::Lexer::parseComplexEscape): (JSC::Lexer::parseStringSlowCase): (JSC::Lexer::parseTemplateLiteral): * parser/Lexer.h: 2020-04-03 Yusuke Suzuki [JSC] canonicalizeLocaleList should gracefully throw OOM error if input + error message is too large https://bugs.webkit.org/show_bug.cgi?id=209971 Reviewed by Mark Lam. canonicalizeLocaleList generates error-message with input. If input is too large, error-message string generation could fail due to OOM. We should gracefully throw OOM error instead of crashing. This strategy follows to `createError`'s error-message generation: if error-message generation fails, throwing OOM error. * runtime/IntlObject.cpp: (JSC::canonicalizeLocaleList): 2020-04-03 Ross Kirsling Move Intl tests from LayoutTests to JSTests https://bugs.webkit.org/show_bug.cgi?id=209922 Reviewed by Yusuke Suzuki. * tools/JSDollarVM.cpp: (JSC::functionSetUserPreferredLanguages): (JSC::JSDollarVM::finishCreation): Add $vm.setUserPreferredLanguages, as needed by stress/intl-default-locale.js. 2020-04-03 Devin Rousso Web Inspector: increase the auto-inspect debugger timeout delay to account for slower networks/devices https://bugs.webkit.org/show_bug.cgi?id=209940 Reviewed by Joseph Pecoraro. * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): 2020-04-03 Yusuke Suzuki [JSC] TypedArray#subarray should throw OOM error gracefully https://bugs.webkit.org/show_bug.cgi?id=209974 Reviewed by Mark Lam. After r259069 change, possiblySharedBuffer can return nullptr if OOM happens. However, TypedArray#subarray didn't handle this case properly. This patch throws an OOM error appropriately if possiblySharedBuffer returns nullptr in TypedArray#subarray. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): 2020-04-03 David Kilzer [Xcode] Replace ASAN_OTHER_CFLAGS and ASAN_OTHER_CPLUSPLUSFLAGS with $(inherited) Reviewed by Alexey Proskuryakov. * Configurations/Base.xcconfig: * Configurations/ToolExecutable.xcconfig: - Remove ASAN_OTHER_CFLAGS, ASAN_OTHER_CPLUSPLUSFLAGS and ASAN_OTHER_LDFLAGS. 2020-04-03 Yusuke Suzuki Unreviewed, partially reverting Structure change due to Speedometer2 regression https://bugs.webkit.org/show_bug.cgi?id=207827 Not reverting WTF changes. * bytecode/AccessCase.cpp: (JSC::AccessCase::createTransition): (JSC::AccessCase::createDelete): (JSC::AccessCase::propagateTransitions const): * bytecode/AccessCase.h: (JSC::AccessCase::structure const): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileObjectKeys): (JSC::DFG::SpeculativeJIT::compileCreateThis): (JSC::DFG::SpeculativeJIT::compileCreatePromise): (JSC::DFG::SpeculativeJIT::compileCreateInternalFieldObject): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys): (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::loadStructureClassInfo): Deleted. (JSC::FTL::DFG::LowerDFGToB3::loadStructureCachedPrototypeChainOrRareData): Deleted. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitLoadClassInfoFromStructure): Deleted. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_create_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_create_this): * jit/Repatch.cpp: (JSC::tryCachePutByID): (JSC::tryCacheDeleteBy): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createStructure): * runtime/ConcurrentJSLock.h: (JSC::ConcurrentJSLockerBase::ConcurrentJSLockerBase): (JSC::GCSafeConcurrentJSLocker::GCSafeConcurrentJSLocker): (JSC::GCSafeConcurrentJSLocker::~GCSafeConcurrentJSLocker): (JSC::ConcurrentJSLocker::ConcurrentJSLocker): (JSC::GCSafeConcurrentJSLockerImpl::GCSafeConcurrentJSLockerImpl): Deleted. (JSC::GCSafeConcurrentJSLockerImpl::~GCSafeConcurrentJSLockerImpl): Deleted. (JSC::ConcurrentJSLockerImpl::ConcurrentJSLockerImpl): Deleted. * runtime/JSCell.h: * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): (JSC::JSObject::shiftButterflyAfterFlattening): * runtime/JSObject.h: (JSC::JSObject::getDirectConcurrently const): * runtime/JSObjectInlines.h: (JSC::JSObject::prepareToPutDirectWithoutTransition): * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains const): (JSC::StructureTransitionTable::get const): (JSC::StructureTransitionTable::add): (JSC::Structure::dumpStatistics): (JSC::Structure::Structure): (JSC::Structure::create): (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::materializePropertyTable): (JSC::Structure::addPropertyTransitionToExistingStructureImpl): (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): (JSC::Structure::addNewPropertyTransition): (JSC::Structure::removePropertyTransitionFromExistingStructureConcurrently): (JSC::Structure::removeNewPropertyTransition): (JSC::Structure::changePrototypeTransition): (JSC::Structure::attributeChangeTransition): (JSC::Structure::toDictionaryTransition): (JSC::Structure::takePropertyTableOrCloneIfPinned): (JSC::Structure::nonPropertyTransitionSlow): (JSC::Structure::flattenDictionaryStructure): (JSC::Structure::pin): (JSC::Structure::pinForCaching): (JSC::Structure::allocateRareData): (JSC::Structure::ensurePropertyReplacementWatchpointSet): (JSC::Structure::copyPropertyTableForPinning): (JSC::Structure::add): (JSC::Structure::remove): (JSC::Structure::visitChildren): (JSC::Structure::canCachePropertyNameEnumerator const): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::get): (JSC::Structure::forEachPropertyConcurrently): (JSC::Structure::transitivelyTransitionedFrom): (JSC::Structure::prototypeChain const): (JSC::Structure::propertyReplacementWatchpointSet): (JSC::Structure::checkOffsetConsistency const): (JSC::Structure::add): (JSC::Structure::remove): (JSC::Structure::removePropertyWithoutTransition): (JSC::Structure::setPropertyTable): (JSC::Structure::setPreviousID): (JSC::Structure::ruleOutUnseenProperty const): Deleted. (JSC::Structure::seenProperties const): Deleted. (JSC::Structure::addPropertyHashAndSeenProperty): Deleted. (JSC::Structure::cachedPrototypeChain const): Deleted. (JSC::Structure::setCachedPrototypeChain): Deleted. (JSC::Structure::clearPropertyTable): Deleted. (JSC::Structure::setOutOfLineTypeFlags): Deleted. (JSC::Structure::setInlineCapacity): Deleted. (JSC::Structure::setClassInfo): Deleted. (JSC::Structure::clearPreviousID): Deleted. * runtime/StructureRareData.cpp: (JSC::StructureRareData::createStructure): (JSC::StructureRareData::create): (JSC::StructureRareData::StructureRareData): (JSC::StructureRareData::visitChildren): * runtime/StructureRareData.h: * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setPreviousID): (JSC::StructureRareData::clearPreviousID): (JSC::StructureRareData::setCachedPrototypeChain): Deleted. * runtime/StructureTransitionTable.h: * tools/JSDollarVM.cpp: (JSC::JSDollarVMHelper::functionGetStructureTransitionList): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): 2020-04-02 Alexey Shvayka TypedArray's [[DefineOwnProperty]] is incorrect with partial descriptors https://bugs.webkit.org/show_bug.cgi?id=188875 Reviewed by Ross Kirsling. This change implements steps 3.b.iv-v of TypedArray's [[DefineOwnProperty]] method [1], preventing type errors from being thrown if descriptor lacks [[Enumerable]] or [[Writable]] field and aligning JSC with V8 and SpiderMonkey. [1]: https://tc39.es/ecma262/#sec-integer-indexed-exotic-objects-defineownproperty-p-desc * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::defineOwnProperty): 2020-04-02 Commit Queue Unreviewed, reverting r259390. https://bugs.webkit.org/show_bug.cgi?id=209944 It broke WinCairo builds (Requested by fujihiro on #webkit). Reverted changeset: "Enable offlineasm debug annotations for GCC" https://bugs.webkit.org/show_bug.cgi?id=207119 https://trac.webkit.org/changeset/259390 2020-04-02 Yusuke Suzuki [JSC] RecordedStatuses's assignment should be guarded by CodeBlock's lock https://bugs.webkit.org/show_bug.cgi?id=209935 Reviewed by Mark Lam. Previously RecordedStatuses are not touched by GC. But now, GC visits RecordedStatuses. This means that modifying RecordedStatuses should be guarded by CodeBlock's lock if it is reachable from CodeBlock. In DFG::Plan::reallyAdd, we already installed DFG::JITCode into the CodeBlock so that RecordedStatuses is reachable from CodeBlock. We should lock CodeBlock's lock while performing `WTFMove(RecordedStatuses)`. We do not need to emit write-barrier here because (1) DFG::Plan::reallyAdd is executed while GC is deferred and (2) we emit write-barrier to CodeBlock before deferred GC is executed. * dfg/DFGPlan.cpp: (JSC::DFG::Plan::reallyAdd): 2020-04-02 Mark Lam HeapSnapshotBuilder::analyzeNode() should filter out duplicate cells. https://bugs.webkit.org/show_bug.cgi?id=209929 Reviewed by Keith Miller. HeapSnapshot::finalize() assumes that its list of cells contain no duplicate cells. HeapSnapshot::appendNode() expects to only be called once for a cell. It doesn't check for duplicates. However, with the concurrent GC marker, there’s a racy chance that the same cell is visited more than once by SlotVisitor, and therefore, SlotVisitor may call HeapSnapshotBuilder::analyzeNode() (and HeapSnapshot::appendNode()) more than once for the same cell. The easiest and cleanest fix for this is to simply keep a HashSet of appended cells in HeapSnapshotBuilder while it is building the snapshot. We can then use the hash set to filter out already appended cells, and avoid adding duplicates to the HeapSnapshot. * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::buildSnapshot): (JSC::HeapSnapshotBuilder::analyzeNode): * heap/HeapSnapshotBuilder.h: 2020-04-02 Angelos Oikonomopoulos Enable offlineasm debug annotations for GCC https://bugs.webkit.org/show_bug.cgi?id=207119 Reviewed by Darin Adler. This simply reuses the existing code that generates debug annotations, adding two workarounds for limitations in GCC and GDB. First, the .file directives that offlineasm inserts in inline asm use file slots that conflict with those in the compilation unit that includes LLIntAssembly.h (specifically, LowLevelInterpreter.cpp). Clang's built-in assembler will transparently fix that for us, but for GCC we need to post-process the generated assembler. Unfortunately, cmake doesn't allow us to introduce a compiler wrapper for a single source file, so we need to create a separate target for it. This wrapping only happens when building with GCC and the user has explicitly requested debug information, either by selecting a Debug/RelWithDebInfo build or setting GCC_OFFLINEASM_SOURCE_MAP. Second, GDB will only look at the line table for a compilation unit if it can first resolve the address to one of the known symbols in the file. Introduce marker symbols to work around this bug. * CMakeLists.txt: 2020-04-01 Ross Kirsling Intl.NumberFormat.prototype.format must preserve sign of -0 https://bugs.webkit.org/show_bug.cgi?id=209880 Reviewed by Keith Miller. The spec changed here two years ago: https://github.com/tc39/ecma402/pull/232 * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::formatNumber): Do NOT throw away the sign of -0. 2020-04-01 Justin Michaud Delete IC incorrectly caches for proxies https://bugs.webkit.org/show_bug.cgi?id=209777 Reviewed by Mark Lam. Proxy's do not change their structure ID when properties are added, so we cannot cache deletes for them. * jit/Repatch.cpp: (JSC::tryCacheDeleteBy): 2020-04-01 Keith Miller Bindings that override getOwnPropertySlotByIndex need to say they MayHaveIndexedAccessors https://bugs.webkit.org/show_bug.cgi?id=209762 Reviewed by Darin Adler. Change indexingType to indexingModeIncludingHistory to more clearly indicate the expected range of possible valid values. * runtime/StructureInlines.h: (JSC::Structure::create): 2020-03-31 Yusuke Suzuki [JSC] Introduce UCPUStrictInt32 for result type of DFG operations https://bugs.webkit.org/show_bug.cgi?id=209832 Reviewed by Saam Barati. Let's introduce UCPUStrictInt32 to DFG operations to offload StrictInt32 code into operations C++ code. UCPUStrictInt32 is the same size to UCPURegister, and it is used for StrictInt32, which requires upper 32-bits are zeroed. * assembler/CPU.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult): (JSC::DFG::SpeculativeJIT::compileBitwiseNot): (JSC::DFG::SpeculativeJIT::compileBitwiseOp): (JSC::DFG::SpeculativeJIT::compileShiftOp): (JSC::DFG::SpeculativeJIT::compileArithAdd): (JSC::DFG::SpeculativeJIT::compileArithAbs): (JSC::DFG::SpeculativeJIT::compileArithClz32): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArithMod): (JSC::DFG::SpeculativeJIT::compileArithRounding): (JSC::DFG::SpeculativeJIT::compileArithMinMax): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileGetArrayLength): (JSC::DFG::SpeculativeJIT::compileVarargsLength): (JSC::DFG::SpeculativeJIT::compileGetRestLength): (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): (JSC::DFG::SpeculativeJIT::compileGetEnumerableLength): (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::strictInt32Result): (JSC::DFG::SpeculativeJIT::int32Result): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileStringCodePointAt): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithClz32): (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf): (JSC::FTL::DFG::LowerDFGToB3::compileVarargsLength): (JSC::FTL::DFG::LowerDFGToB3::mapHashString): (JSC::FTL::DFG::LowerDFGToB3::compileMapHash): (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom): (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32): * ftl/FTLOperations.cpp: (JSC::FTL::operationSwitchStringAndGetBranchOffset): (JSC::FTL::operationTypeOfObjectAsTypeofType): * ftl/FTLOperations.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * runtime/MathCommon.cpp: (JSC::operationToInt32): (JSC::operationToInt32SensibleSlow): * runtime/MathCommon.h: (JSC::toUCPUStrictInt32): 2020-03-31 Ross Kirsling REGRESSION: ASSERTION FAILED: regExpObjectNode in JSC::DFG::StrengthReductionPhase::handleNode https://bugs.webkit.org/show_bug.cgi?id=209824 Reviewed by Mark Lam. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): It's true that we need to verify lastIndex even when a RegExp is neither global nor sticky, but if DFG's already converted RegExpExec to RegExpExecNonGlobalOrSticky, that means we've thrown away the RegExpObject node, so we shouldn't try to reverify lastIndex when we reconsider folding to constant. 2020-03-30 Yusuke Suzuki [JSC] DFGArrayMode::alreadyChecked should have NonArray check when ArrayMode is NonArray+SlowPutArrayStorage https://bugs.webkit.org/show_bug.cgi?id=209791 Reviewed by Saam Barati. DFGArrayMode::alreadyChecked with NonArray+SlowPutArrayStorage should check NonArray condition. * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::alreadyChecked const): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::arrayModesWithIndexingShapes const): 2020-03-30 Alexey Shvayka Add support in named capture group identifiers for direct surrogate pairs https://bugs.webkit.org/show_bug.cgi?id=178174 Reviewed by Darin Adler and Michael Saboff. This change: a) Adds support for unescaped astral symbols in RegExp identifier names [1], aligning JSC with V8. b) Rewords InvalidUnicodeEscape error code to be used for \uXXXX escapes in Unicode patterns and named groups/references instead of InvalidIdentityEscape, matching error messages in V8 and SpiderMonkey. c) Adds hasError() checks after tryConsumeGroupName() so errors generated in tryConsumeIdentifierCharacter() would not get overriden. d) Removes code duplication by using tryConsumeUnicodeEscape() for parsing \u in parseEscape(); cleans up parsing \u{} escapes a bit, preferring ASSERTs over hasError() checks. [1]: https://tc39.es/ecma262/#prod-RegExpIdentifierName * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::parseParenthesesBegin): (JSC::Yarr::Parser::tryConsumeUnicodeEscape): (JSC::Yarr::Parser::tryConsumeIdentifierCharacter): 2020-03-30 Ross Kirsling RegExp.prototype.exec must always access lastIndex https://bugs.webkit.org/show_bug.cgi?id=209375 Reviewed by Saam Barati. From https://tc39.es/ecma262/#sec-regexpbuiltinexec: 21.2.5.2.2 Runtime Semantics: RegExpBuiltinExec ( R, S ) ... 4. Let lastIndex be ? ToLength(? Get(R, "lastIndex")). ... 8. If global is false and sticky is false, set lastIndex to 0. That is, we're always obliged to verify that lastIndex is Number-coercible, even if we don't use the value. DFG, in particular, must make sure strength reductions don't apply when lastIndex isn't an unsigned integer (i.e., when user code has written something strange to it). foldToConstant already has an early out for this, but it needs to apply to convertToStatic too. Furthermore, ToLength clamps negative values to 0, so correct getRegExpObjectLastIndexAsUnsigned accordingly. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * runtime/RegExpObjectInlines.h: (JSC::getRegExpObjectLastIndexAsUnsigned): (JSC::RegExpObject::execInline): (JSC::RegExpObject::matchInline): 2020-03-30 Don Olmstead Non-unified build fixes late March 2020 edition https://bugs.webkit.org/show_bug.cgi?id=209781 Unreviewed build fix. * jit/JITInlineCacheGenerator.h: 2020-03-30 Devin Rousso Web Inspector: provide a way to log messages from the network process https://bugs.webkit.org/show_bug.cgi?id=204775 Reviewed by Brian Burg. ITP can be influenced by multiple pages simultaneously, meaning that sending a console message to the Web Inspector that's connected to the page that caused a change may not be useful as developers often don't test in complete isolation. As such, having a way to broadcast a console message to all Web Inspectors ensures that any changes caused by any page are always able to be seen, no matter which page is being actively inspected. * inspector/protocol/Console.json: * inspector/scripts/codegen/generator.py: * runtime/ConsoleTypes.h: * runtime/ConsoleClient.cpp: (JSC::appendMessagePrefix): * inspector/ConsoleMessage.cpp: (Inspector::messageSourceValue): Add `ITPDebug` and `AdClickAttribution` message sources. 2020-03-30 Keith Miller Unreviewed, add FIXME. * runtime/IndexingType.h: 2020-03-30 Caio Lima [JSC] Public class field should accept "static" as field name https://bugs.webkit.org/show_bug.cgi?id=209703 Reviewed by Ross Kirsling. It allows class fields being created using "static" as identifier (https://tc39.es/ecma262/#prod-IdentifierName). * parser/Parser.cpp: (JSC::Parser::parseClass): 2020-03-28 Yusuke Suzuki [JSC] Use CacheableIdentifier for all ById case https://bugs.webkit.org/show_bug.cgi?id=209698 Reviewed by Saam Barati. StructureStubInfo & AccessCase holds CacheableIdentifier to keep cell identifiers alive. We are assuming that operationGetById...'s identifier is always owned by CodeBlock, and we call CacheableIdentifier::createFromIdentifierOwnedByCodeBlock for UniquedStringImpl*. This is wrong since GetById IC can be generated with identifier which is not owned by CodeBlock. Let's consider the following case, 1. op_get_by_val gets GetById IC. CacheableIdentifier is kept by StructureStubInfo/AccessCase correctly. 2. This CodeBlock gets DFG. 3. DFG understand op_get_by_val and emit GetById DFG node since it only has one identifier. 4. Then, DFG can generate GetById DFG code which generates GetById IC 5. (4)'s GetById IC gets executed. But this IC considers that identifier is owned by CodeBlock since this is ById IC. 6. New DFG CodeBlock starts compilation. And it gets feedback from (2)'s get_by_val's StructureStubInfo, so it emits GetById with non-cell CacheableIdentifier! So it does not retain the cell. It just registers desired identifier. 7. While compiling (6) (after parsing bytecode), (2)'s CodeBlock's DFG code & IC gets jettisoned. And then, identifier used in (6) gets destroyed too. 8. (6)'s CodeBlock finalizes its compilation, registering desired identifiers to the actual CodeBlock. And it found the identifier gets destroyed. In this patch, 1. CacheableIdentifier::createFromIdentifierOwnedByCodeBlock is called only when the creator knowns that this is owned by the CodeBlock. Typically, this is when the code generator generates IC. 2. operationGetById... functions get CacheableIdentifier instead of UniquedStringImpl*. So it propagates whether the given CacheableIdentifier is created from CodeBlock's identifier or cells. 3. AccessCase holds this propagated CacheableIdentifiers. If CacheableIdentifiers is created from a cell in some tier's IC, then it continues to be represented as a cell-origin CacheableIdentifiers regardless of whether the current IC is GetById / GetByVal. Then GC marks it correctly. 4. This patch does the same thing to all the ICs. 5. This patch extends StructureStubInfo / AccessCase to pave the way to use them in PutByVal / InByVal by introducing CacheableIdentifier for Put and In. * bytecode/AccessCase.cpp: (JSC::AccessCase::fromStructureStubInfo): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::initPutByIdReplace): (JSC::StructureStubInfo::initInByIdSelf): (JSC::StructureStubInfo::visitAggregate): (JSC::StructureStubInfo::setCacheType): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::identifier): (JSC::StructureStubInfo::considerCachingBy): (JSC::StructureStubInfo::getByIdSelfIdentifier): Deleted. (JSC::StructureStubInfo::considerCachingById): Deleted. (JSC::StructureStubInfo::considerCachingByVal): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArrayMode.cpp: (JSC::DFG::canBecomeGetArrayLength): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::emitPutById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::addStringReplacePrimordialChecks): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::convertToInById): (JSC::DFG::Node::hasCacheableIdentifier): (JSC::DFG::Node::cacheableIdentifier): (JSC::DFG::Node::hasIdentifier): (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper): (JSC::DFG::Node::OpInfoWrapper::operator=): * dfg/DFGOpInfo.h: (JSC::DFG::OpInfo::OpInfo): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetById): (JSC::DFG::SpeculativeJIT::compileGetByIdFlush): (JSC::DFG::SpeculativeJIT::compileInById): (JSC::DFG::SpeculativeJIT::compilePutByIdFlush): (JSC::DFG::SpeculativeJIT::compilePutById): (JSC::DFG::SpeculativeJIT::compilePutByIdDirect): (JSC::DFG::SpeculativeJIT::compilePutByIdWithThis): (JSC::DFG::SpeculativeJIT::cachedPutById): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileDeleteById): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileDeleteById): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutById): (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteById): (JSC::FTL::DFG::LowerDFGToB3::compileInById): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITGetByIdGenerator::JITGetByIdGenerator): (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): (JSC::JITPutByIdGenerator::JITPutByIdGenerator): (JSC::JITPutByIdGenerator::slowPathFunction): (JSC::JITDelByIdGenerator::JITDelByIdGenerator): (JSC::JITInByIdGenerator::JITInByIdGenerator): * jit/JITInlineCacheGenerator.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emitSlow_op_del_by_id): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emitByValIdentifierCheck): (JSC::JIT::privateCompilePutByValWithCachedId): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): * jit/Repatch.cpp: (JSC::appropriateGenericPutByIdFunction): (JSC::appropriateOptimizingPutByIdFunction): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryCacheInByID): (JSC::repatchInByID): (JSC::resetPutByID): * jit/Repatch.h: * runtime/CacheableIdentifier.cpp: (JSC::CacheableIdentifier::dump const): * runtime/CacheableIdentifier.h: (JSC::CacheableIdentifier::createFromRawBits): (JSC::CacheableIdentifier::rawBits const): (JSC::CacheableIdentifier::CacheableIdentifier): * runtime/CacheableIdentifierInlines.h: (JSC::CacheableIdentifier::createFromIdentifierOwnedByCodeBlock): (JSC::CacheableIdentifier::createFromImmortalIdentifier): (JSC::CacheableIdentifier::CacheableIdentifier): 2020-03-28 Devin Rousso Web Inspector: support editing cookie key/values from inspector https://bugs.webkit.org/show_bug.cgi?id=31157 Reviewed by Timothy Hatcher. * inspector/protocol/Page.json: Add a `session` parameter to `Page.Cookie` type and a new `Page.setCookie` command. Remove the `size` parameter from `Page.Cookie` as this can be calculated in the frontend. 2020-03-27 Ross Kirsling [JSC] Make Operator an enum class to avoid Op* identifiers https://bugs.webkit.org/show_bug.cgi?id=209637 Reviewed by Darin Adler. Currently, (e.g.) OpLShift is a value of enum Operator while OpLshift is an opcode. Capitalization aside, it's confusing to be using Op* for disparate purposes like this. Let's modernize the enum so that this confusion can go away as a side effect. * bytecompiler/NodesCodegen.cpp: (JSC::emitIncOrDec): (JSC::PostfixNode::emitBytecode): (JSC::PrefixNode::emitBytecode): (JSC::LogicalOpNode::emitBytecode): (JSC::LogicalOpNode::emitBytecodeInConditionContext): (JSC::emitReadModifyAssignment): (JSC::ReadModifyDotNode::emitBytecode): (JSC::ReadModifyBracketNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::makeBinaryNode): (JSC::ASTBuilder::makeAssignNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseUnaryExpression): 2020-03-19 Tadeu Zagallo Fix instances of new.target that should be syntax errors https://bugs.webkit.org/show_bug.cgi?id=208040 Reviewed by Michael Saboff. We were not throwing the appropriate syntax errors for the following usages of new.target: - Class field initializers outside ordinary functions: we were missing a check that the closestOrdinaryFunctionScope was not the global scope. - Within an eval inside an arrow function: we were only checking that the EvalContextType should be FunctionEvalContext, but that does not tell us whether it's an arrow function or an ordinary function. To fix that we must thread that information from the executables to the parser. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::link): * bytecode/UnlinkedFunctionExecutable.h: * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::evaluateWithScopeExtension): * interpreter/Interpreter.cpp: (JSC::eval): * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::parse): * runtime/CodeCache.cpp: (JSC::generateUnlinkedCodeBlockImpl): * runtime/DirectEvalExecutable.cpp: (JSC::DirectEvalExecutable::create): (JSC::DirectEvalExecutable::DirectEvalExecutable): * runtime/DirectEvalExecutable.h: * runtime/EvalExecutable.cpp: (JSC::EvalExecutable::EvalExecutable): * runtime/EvalExecutable.h: * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::FunctionExecutable): * runtime/FunctionExecutable.h: * runtime/GlobalExecutable.h: (JSC::GlobalExecutable::GlobalExecutable): * runtime/IndirectEvalExecutable.cpp: (JSC::IndirectEvalExecutable::IndirectEvalExecutable): * runtime/ModuleProgramExecutable.cpp: (JSC::ModuleProgramExecutable::ModuleProgramExecutable): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::ProgramExecutable): * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::ScriptExecutable): * runtime/ScriptExecutable.h: (JSC::ScriptExecutable::isInsideOrdinaryFunction const): 2020-03-27 Keith Miller Add missing scope release to DataView's buffer getter https://bugs.webkit.org/show_bug.cgi?id=209663 Reviewed by Yusuke Suzuki. * runtime/JSDataViewPrototype.cpp: (JSC::dataViewProtoGetterBuffer): 2020-03-26 Mark Lam Clear the entropy bits in the encodedStructureBits when deallocating a structureID. https://bugs.webkit.org/show_bug.cgi?id=209632 Reviewed by Saam Barati. We currently only use a 32-bit offset in the StructureIDTable's StructureOrOffset. Though we will never store an offset value that is near 32-bit in size, let alone 64-bit, there's no reason why we can't just use all 64-bits for the offset. Doing so will also have the benefit of zero'ing out the entropy bits in the old encodedStructureBits. This guarantees that there's no chance of coalition between a "freed" structureID's entropy bits and the entropy bits in a dead cell due to GC bugs. * runtime/StructureIDTable.h: 2020-03-26 Fujii Hironori [Win] lld-link: error: /manifestdependency: is not allowed in .drectve https://bugs.webkit.org/show_bug.cgi?id=204831 Reviewed by Ross Kirsling. * shell/DLLLauncherMain.cpp: Removed /manifestdependency for Microsoft.VC80.CRT which seems leftover of Bug 116562 (r178530). 2020-03-26 Ross Kirsling [JSC] Rename ANDEQUAL to BITANDEQUAL (etc.) throughout frontend https://bugs.webkit.org/show_bug.cgi?id=209626 Reviewed by Mark Lam. Our frontend refers to `&=` `|=` `^=` as `ANDEQUAL` `OREQUAL` `XOREQUAL`, leaving the bitwiseness implied. It's important to resolve this ambiguity now, as `&&=` `||=` `??=` are expected to reach Stage 3 next week. * bytecompiler/NodesCodegen.cpp: (JSC::emitReadModifyAssignment): * parser/Lexer.cpp: (JSC::Lexer::lexWithoutClearingLineTerminator): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::parseAssignmentExpression): * parser/ParserTokens.h: 2020-03-26 Michael Saboff Refactor YARR Stack Overflow Checks https://bugs.webkit.org/show_bug.cgi?id=209435 rdar://problem/58988252 Reviewed by Mark Lam. Refactored stack checks in YARR code including adding a stack check to the YARR JIT'ed code. The C++ code including the parser, byte code compiler and interpreter now all use StackCheck. The JIT'ed code needs a stack limit passed via a parameter since the JIT'ed code can be called from the compiler thread when compiling DFG / FTL code. Instead of adding a new parameter, consolidated the two pattern context buffer values, buffer pointer and size, with the new stack limit into a new MatchingContextHolder, an RAII object. The MatchingContextHolder constructor uses either the VM stack limit or the current thread's stack limit depending on how it is called. * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::byteCodeCompileIfNecessary): (JSC::RegExp::compile): (JSC::RegExp::matchConcurrently): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): (JSC::PatternContextBufferHolder::PatternContextBufferHolder): Deleted. (JSC::PatternContextBufferHolder::~PatternContextBufferHolder): Deleted. (JSC::PatternContextBufferHolder::buffer): Deleted. (JSC::PatternContextBufferHolder::size): Deleted. (): Deleted. * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::matchDisjunction): (JSC::Yarr::Interpreter::isSafeToRecurse): * yarr/YarrJIT.cpp: (JSC::Yarr::MatchingContextHolder::MatchingContextHolder): (JSC::Yarr::MatchingContextHolder::~MatchingContextHolder): (JSC::Yarr::YarrGenerator::initParenContextFreeList): (JSC::Yarr::YarrGenerator::alignCallFrameSizeInBytes): (JSC::Yarr::YarrGenerator::compile): (JSC::Yarr::YarrGenerator::initCallFrame): Deleted. * yarr/YarrJIT.h: (JSC::Yarr::MatchingContextHolder::offsetOfStackLimit): (JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBuffer): (JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBufferSize): (JSC::Yarr::YarrCodeBlock::execute): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor): (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse): (JSC::Yarr::YarrPattern::compile): (JSC::Yarr::YarrPattern::YarrPattern): (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const): Deleted. * yarr/YarrPattern.h: 2020-03-26 Keith Miller TypedArrays should more gracefully handle OOM during slowDownAndWasteMemory https://bugs.webkit.org/show_bug.cgi?id=209611 Reviewed by Tadeu Zagallo. Right now if we cannot allocate an ArrayBuffer for a TypedArray we crash. However, since we use the primitive gigacage for ArrayBuffer allocations we can likely still allocate an OOM error object. In order to do this some changes were needed in slowDownAndWasteMemory. Namely, we should not allocate the butterfly until we know we have an ArrayBuffer. I also check that all the transitive callers of slowDownAndWasteMemory can handle failure. Lastly, this patch makes it so failure to allocate an ArrayBuffer for a TypeArray during DFG watchpoint addition causes the code block to be thrown away, rather than crash the process. * API/JSTypedArray.cpp: (JSObjectGetTypedArrayBytesPtr): (JSObjectGetTypedArrayBuffer): * bytecode/Watchpoint.h: * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add): * runtime/GenericTypedArrayViewInlines.h: (JSC::GenericTypedArrayView::tryCreate): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::unsharedBuffer): (JSC::JSArrayBufferView::unsharedJSBuffer): (JSC::JSArrayBufferView::possiblySharedJSBuffer): (JSC::JSArrayBufferView::slowDownAndWasteMemory): (JSC::JSArrayBufferView::possiblySharedImpl): * runtime/JSArrayBufferViewInlines.h: (JSC::JSArrayBufferView::byteOffsetImpl): 2020-03-26 Commit Queue Unreviewed, reverting r259035. https://bugs.webkit.org/show_bug.cgi?id=209597 broke windows layout-tests (Requested by aakashjain on #webkit). Reverted changeset: "[Win] lld-link: error: /manifestdependency: is not allowed in .drectve" https://bugs.webkit.org/show_bug.cgi?id=204831 https://trac.webkit.org/changeset/259035 2020-03-25 Fujii Hironori [Win] lld-link: error: /manifestdependency: is not allowed in .drectve https://bugs.webkit.org/show_bug.cgi?id=204831 Reviewed by Ross Kirsling. * shell/DLLLauncherMain.cpp: Removed /manifestdependency for Microsoft.VC80.CRT which seems leftover of Bug 116562 (r178530). 2020-03-25 Alexey Shvayka RegExp.prototype[@@replace] relies on globals and doesn't perform ToLength https://bugs.webkit.org/show_bug.cgi?id=173867 Reviewed by Ross Kirsling. This change: a) Adds "lastIndex" ToLength coercion [1], which is observable, unlike ToLength coercion of RegExpExec result [2] that we omit, just like the one in @@split [3]. b) Removes `lastPosition` checks/updates, as there are none in the spec, and it was equivalent to checking `nextSourcePosition`. c) Removes reliance of @@replace on globals and also replaces @stringSubstrInternal built-in with @stringSubstringInternal, as the former is Annex B and accepts size as 2nd paramter, which is not very handy because ECMA-262 usually says "substring of S consisting of the code units at indices X (inclusive) through Y (exclusive)". [1]: https://tc39.es/ecma262/#sec-regexp.prototype-@@replace (step 11.c.iii.2.a) [2]: https://tc39.es/ecma262/#sec-regexp.prototype-@@replace (step 14.a) [3]: https://tc39.es/ecma262/#sec-regexp.prototype-@@split (step 19.d.iv.6) * builtins/BuiltinNames.h: * builtins/RegExpPrototype.js: (getSubstitution): (Symbol.replace): (Symbol.split): * builtins/StringPrototype.js: (globalPrivate.repeatCharactersSlowPath): * bytecode/LinkTimeConstant.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/StringPrototype.cpp: (JSC::stringIndexOfImpl): (JSC::stringProtoFuncIndexOf): (JSC::builtinStringIndexOfInternal): (JSC::stringProtoFuncSubstr): (JSC::stringSubstringImpl): (JSC::stringProtoFuncSubstring): (JSC::builtinStringSubstringInternal): (JSC::stringProtoFuncSubstrImpl): Deleted. (JSC::builtinStringSubstrInternal): Deleted. * runtime/StringPrototype.h: 2020-03-25 Alexey Shvayka Invalid numeric and named references should be early syntax errors https://bugs.webkit.org/show_bug.cgi?id=178175 Reviewed by Ross Kirsling. This patch: 1. Fixes named reference parsing in parseEscape(), making /\k/u throw SyntaxError per spec [1]. 2. Reworks containsIllegalNamedForwardReferences(), making dangling (e.g. /\k(?.)/) and incomplete (e.g. /\k<(?.)/) named references throw SyntaxError if the non-Unicode pattern contains a named group [2]. 3. Moves reparsing logic from YarrPattern to YarrParser, ensuring syntax errors due to illegal references (named & numeric) are thrown at parse time; drops isValidNamedForwardReference() from Delegate, refactors saveUnmatchedNamedForwardReferences(), and overall improves cohesion of illegal references logic. [1]: https://tc39.es/ecma262/#prod-IdentityEscape [2]: https://tc39.es/ecma262/#sec-regexpinitialize (step 7.b) * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::CharacterClassParserDelegate::atomNamedBackReference): (JSC::Yarr::Parser::Parser): (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::parseParenthesesBegin): (JSC::Yarr::Parser::parse): (JSC::Yarr::Parser::handleIllegalReferences): (JSC::Yarr::Parser::containsIllegalNamedForwardReference): (JSC::Yarr::Parser::resetForReparsing): (JSC::Yarr::parse): (JSC::Yarr::Parser::CharacterClassParserDelegate::isValidNamedForwardReference): Deleted. * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::atomBackReference): (JSC::Yarr::YarrPatternConstructor::atomNamedForwardReference): (JSC::Yarr::YarrPattern::compile): (JSC::Yarr::YarrPatternConstructor::saveUnmatchedNamedForwardReferences): Deleted. (JSC::Yarr::YarrPatternConstructor::isValidNamedForwardReference): Deleted. * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::resetForReparsing): (JSC::Yarr::YarrPattern::containsIllegalBackReference): Deleted. (JSC::Yarr::YarrPattern::containsIllegalNamedForwardReferences): Deleted. * yarr/YarrSyntaxChecker.cpp: (JSC::Yarr::SyntaxChecker::atomNamedBackReference): (JSC::Yarr::SyntaxChecker::resetForReparsing): (JSC::Yarr::SyntaxChecker::isValidNamedForwardReference): Deleted. 2020-03-25 Chris Dumez Use JSC::EnsureStillAliveScope RAII object in the generated bindings code https://bugs.webkit.org/show_bug.cgi?id=209552 Reviewed by Yusuke Suzuki. Add method to EnsureStillAliveScope to retrieve its internal JSValue. * runtime/JSCJSValue.h: (JSC::EnsureStillAliveScope::value const): 2020-03-25 Chris Dumez Event listeners registered with 'once' option may get garbage collected too soon https://bugs.webkit.org/show_bug.cgi?id=209504 Reviewed by Yusuke Suzuki. Add EnsureStillAliveScope RAII object for ensureStillAliveHere(). * runtime/JSCJSValue.h: (JSC::EnsureStillAliveScope::EnsureStillAliveScope): (JSC::EnsureStillAliveScope::~EnsureStillAliveScope): 2020-03-25 Alexey Shvayka \b escapes inside character classes should be valid in Unicode patterns https://bugs.webkit.org/show_bug.cgi?id=209528 Reviewed by Darin Adler. This change removes isIdentityEscapeAnError('b') check, allowing \b escapes inside character classes in Unicode patterns match U+0008 (BACKSPACE) characters, aligning JSC with V8 and SpiderMonkey. Grammar: https://tc39.es/ecma262/#prod-ClassEscape ('b' comes before CharacterEscape :: IdentityEscape) * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): 2020-03-24 Ross Kirsling Introduce @tryGetByIdWithWellKnownSymbol instead of repurposing @tryGetById itself https://bugs.webkit.org/show_bug.cgi?id=209524 Reviewed by Saam Barati and Yusuke Suzuki. r258865 allowed @tryGetById to take any ResolveNode, such that a built-in could pass a well-known symbol. This is much more permissive than necessary, since we shouldn't really need a ResolveNode in the first place; instead, let's make a new bytecode intrinsic function @tryGetByIdWithWellKnownSymbol for this purpose. * builtins/RegExpPrototype.js: (globalPrivate.hasObservableSideEffectsForRegExpSplit): * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById): Revert change from r258865. (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetByIdWithWellKnownSymbol): Added. 2020-03-24 Tadeu Zagallo LLIntGenerator must link switch jumps to otherwise redundant labels https://bugs.webkit.org/show_bug.cgi?id=209333 Reviewed by Saam Barati. The LLIntGenerator optimizes jumps at the end of blocks. It does so when a block ends, by checking if the last instruction emitted was a jump, if it pointed to the end of the current block and if it was the only jump that pointed there. If all those conditions are satisfied, the jump is removed and it's not necessary to emit the label at the end of block, since the only jump that pointed to it was removed. However, switches (br_table) are handled specially by the LLIntGenerator and therefore are not counted in Label::unresolvedJumps, which was used to check whether we could skip emitting the label. The end result is that we might skip linking a switch jump if it points to a block that ends with a jump. * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::addEndToUnreachable): (JSC::Wasm::LLIntGenerator::linkSwitchTargets): (JSC::GenericLabel::setLocation): 2020-03-24 Saam Barati Memory::fastMappedBytes() is wrong https://bugs.webkit.org/show_bug.cgi?id=209488 Reviewed by Mark Lam. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::fastMappedBytes): 2020-03-24 Keith Miller Fix isEmpty AssemblyHelpers function and add isNotEmpty https://bugs.webkit.org/show_bug.cgi?id=209507 Reviewed by Saam Barati. This fixes the 32 version of my HasIndexedProperty patch as well as properly names the functions for what they do. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::isEmpty): (JSC::AssemblyHelpers::isNotEmpty): 2020-03-23 Keith Miller HasIndexedProperty should know about sane chain https://bugs.webkit.org/show_bug.cgi?id=209457 Reviewed by Saam Barati. This patch makes it so HasIndexedProperty is aware of sane chain. This is useful because, most of the time we do an indexed in it is on an array. If the array has a sane chain (i.e. no indexed properties on it's prototypes and has the default prototype chain) then we can just test for the index being a hole. Note, we could also just convert OOB indices into false but that should happen in another patch. https://bugs.webkit.org/show_bug.cgi?id=209456 I didn't add any tests because it turns out we already have a ton. I know this because I broke most of them repeatedly... >.> * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::setSaneChainIfPossible): (JSC::DFG::FixupPhase::convertToHasIndexedProperty): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty): (JSC::FTL::DFG::LowerDFGToB3::speculateAndJump): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::isEmpty): 2020-03-23 Yusuke Suzuki [JSC] Caller of Delete IC should emit write-barrier onto owner https://bugs.webkit.org/show_bug.cgi?id=209392 Reviewed by Saam Barati. DeleteIC can change Structure of the owner cell in the fast path. However it is not emitting write-barrier, while we are writing a Structure cell id into a JSObject's header. In this patch, 1. Emit write-barrier in baseline. Be careful about when emitting write-barrier since it clobbers registers. 2. DFG and FTL recognize DeleteById / DeleteByVal in DFGStoreBarrierInsertionPhase. 3. DFGStoreBarrierInsertionPhase only accepts nodes which base is speculated as a Cell. Current DeleteById / DeleteByVal can have UntypedUse base value, but we miss emitting write-barrier DeleteById / DeleteByVal with UntypedUse in the fast path. In this patch, we optimize DeleteById / DeleteByVal only when we speculate child1 as a cell. We can take the further steps after fixing this bug, e.g. (1) accepting UntypedUse in store-barrier-insertion[1] or (2) emitting write-barrier if child1's speculation is UntypedUse. For now, we fix the bug by taking a generic path when child1 is not speculated as a cell. And we can optimize it in a separate change[2]. This is following the design of PutIC. Currently, we use ShouldFilterBase for emitWriteBarrier. But we could use UnconditionalWriteBarrier here since we already filter non-cells in Baseline's hot path. I filed it as a separate bug in [3]. [1]: https://bugs.webkit.org/show_bug.cgi?id=209396 [2]: https://bugs.webkit.org/show_bug.cgi?id=209397 [3]: https://bugs.webkit.org/show_bug.cgi?id=209395 * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileDeleteById): (JSC::DFG::SpeculativeJIT::compileDeleteByVal): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDeleteById): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitWriteBarrier): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_put_by_id): 2020-03-23 Yusuke Suzuki [JSC] DFG OSR exit cannot find StructureStubInfo for put_by_val if CodeBlock is once converved from Baseline to LLInt https://bugs.webkit.org/show_bug.cgi?id=209327 Reviewed by Saam Barati. DFG compiles op_put_by_val as PutById and inlines SetterCall only when DFG found StructureStubInfo for this op_put_by_val. However, it is still possible that DFG OSR exit cannot find StructureStubInfo for SetterCall generated by op_put_by_val. Let's consider the following scenario. 1. Baseline CodeBlock (A) is compiled. 2. (A) gets DFG (B). 3. Since (A) collects enough information for put_by_val, (B) can get StructureStubInfo from (A) and compile it as inlined Setter call. 4. (A)'s JITData is destroyed since it is not executed. Then, (A) becomes LLInt. 5. The CodeBlock inlining (A) gets OSR exit. So (A) is executed and (A) eventually gets Baseline CodeBlock again. 6. (B) gets OSR exit. (B) attempts to search for StructureStubInfo in (A) for PutById (originally, put_by_val). But it does not exist since (A)'s JITData is cleared once. We should just link to doneTarget of ByValInfo when the SetterCall is generated by `op_put_by_val`. ByValInfo and its doneTarget always exists per op_put_by_val. * bytecode/ByValInfo.h: (JSC::ByValInfo::ByValInfo): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::findByValInfo): * bytecode/CodeBlock.h: * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITPropertyAccess.cpp: (JSC::JIT::privateCompilePutByVal): (JSC::JIT::privateCompilePutByValWithCachedId): 2020-03-23 Ross Kirsling Unreviewed, address Yusuke's feedback on r258801. * builtins/RegExpPrototype.js: (globalPrivate.hasObservableSideEffectsForRegExpSplit): * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById): 2020-03-23 Ross Kirsling Catch parameters must not be lexically redeclared https://bugs.webkit.org/show_bug.cgi?id=208976 Reviewed by Keith Miller. From https://tc39.es/ecma262/#sec-try-statement-static-semantics-early-errors: Catch : catch ( CatchParameter ) Block It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the LexicallyDeclaredNames of Block. In other words, let/const/class/function declarations in the immediate catch block scope must not shadow catch parameters. * parser/Parser.cpp: (JSC::Parser::parseTryStatement): (JSC::Parser::parseBlockStatement): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::setIsCatchBlockScope): Added. (JSC::Scope::isCatchBlockScope): Added. (JSC::Parser::declareVariable): (JSC::Parser::declareFunction): 2020-03-23 Michael Catanzaro REGRESSION(r249808): [GTK] Crash in JSC Config::permanentlyFreeze() on architecture ppc64el https://bugs.webkit.org/show_bug.cgi?id=209236 Reviewed by Mark Lam. * heap/MarkedBlock.h: Use new CeilingOnPageSize. * runtime/JSCConfig.cpp: (JSC::Config::permanentlyFreeze): Use pageSize instead of vmPageSize. * runtime/JSCConfig.h: Use new CeilingOnPageSize. 2020-03-22 Yusuke Suzuki Unreviewed, rename keepAlive to ensureStillAliveHere https://bugs.webkit.org/show_bug.cgi?id=209398 Based on Geoff and Mark's feedback, renaming keepAlive to ensureStillAliveHere to make the effect of keepAlive clear. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice): (JSC::FTL::DFG::LowerDFGToB3::ensureStillAliveHere): (JSC::FTL::DFG::LowerDFGToB3::keepAlive): Deleted. * heap/HeapCell.cpp: (JSC::ensureStillAliveHere): (JSC::keepAlive): Deleted. * heap/HeapCell.h: (JSC::ensureStillAliveHere): (JSC::HeapCell::use const): (JSC::keepAlive): Deleted. * runtime/JSCJSValue.cpp: (JSC::ensureStillAliveHere): (JSC::keepAlive): Deleted. * runtime/JSCJSValue.h: (JSC::ensureStillAliveHere): (JSC::keepAlive): Deleted. * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): 2020-03-22 Yusuke Suzuki [JSC] Add JSC::keepAlive(JSValue) https://bugs.webkit.org/show_bug.cgi?id=209398 Reviewed by Mark Lam. Add JSC::keepAlive(JSValue). This is useful to make some JSValue variable alive from GC. * heap/HeapCell.cpp: * runtime/JSCJSValue.cpp: (JSC::keepAlive): * runtime/JSCJSValue.h: (JSC::keepAlive): 2020-03-20 Ross Kirsling hasObservableSideEffectsForRegExpSplit doesn't check for @@match override https://bugs.webkit.org/show_bug.cgi?id=209363 Reviewed by Michael Saboff. Our RegExp.prototype[@@split] implementation has a fast path for unadultered RegExp objects, but we're using that fast path even when @@match has been overridden. This is illegitimate because the RegExp species constructor calls IsRegExp, which hits the @@match getter. * builtins/BuiltinNames.h: * builtins/RegExpPrototype.js: (globalPrivate.hasObservableSideEffectsForRegExpSplit): * bytecode/LinkTimeConstant.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2020-03-20 Ross Kirsling RegExp.prototype[@@replace] doesn't coerce result index to integer https://bugs.webkit.org/show_bug.cgi?id=209323 Reviewed by Yusuke Suzuki. From https://tc39.es/ecma262/#sec-regexp.prototype-@@replace: 21.2.5.10 RegExp.prototype [ @@replace ] ( string, replaceValue ) ... 14. For each result in results, do ... e. Let position be ? ToInteger(? Get(result, "index")). f. Set position to max(min(position, lengthS), 0). result.index may be undefined, so it doesn't suffice to coerce it with comparison operators. * builtins/RegExpPrototype.js: 2020-03-20 Justin Michaud Fix JSCOnly build without unified sources https://bugs.webkit.org/show_bug.cgi?id=209343 Reviewed by Keith Miller. I managed to get clangd to work for code completion using the following command: ./Tools/Scripts/build-webkit --jsc-only --cmakeargs="-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DENABLE_UNIFIED_BUILDS=OFF" && compdb -p WebKitBuild/Release/ list > compile_commands.json This patch fixes the build for non-unified sources, and adds some extra clangd files to .gitignore. * API/MarkedJSValueRefArray.h: * jit/JITPropertyAccess.cpp: 2020-03-20 Tim Horton Upstream a variety of Cocoa-platform HAVE and ENABLE macros https://bugs.webkit.org/show_bug.cgi?id=209307 Reviewed by Andy Estes. * Configurations/FeatureDefines.xcconfig: 2020-03-20 Jacob Uphoff Unreviewed, reverting r258748. This commit broke the Catalina build Reverted changeset: "Upstream a variety of Cocoa-platform HAVE and ENABLE macros" https://bugs.webkit.org/show_bug.cgi?id=209307 https://trac.webkit.org/changeset/258748 2020-03-19 Tim Horton Upstream a variety of Cocoa-platform HAVE and ENABLE macros https://bugs.webkit.org/show_bug.cgi?id=209307 Reviewed by Andy Estes. * Configurations/FeatureDefines.xcconfig: 2020-03-19 Yusuke Suzuki [JSC] StructureStubInfo::bufferedStructures should not ref/deref UniquedStringImpl https://bugs.webkit.org/show_bug.cgi?id=209266 Reviewed by Saam Barati. StructureStubInfo::bufferedStructures includes RefPtr. So destroying StructureStubInfo in CodeBlock::finalizeUnconditionally can access to AtomStringTable, and get nullptr AtomStringTable since CodeBlock::finalizeUnconditionally can be executed in heap-thread. Temporarily setting AtomStringTable in the heap-thread when executing GC End phase is dangerous: Web worker's JSC VM is releasing heapAccess when waiting for the next message in the RunLoop. This potentially means that Web worker's main thread can run concurrently with Web worker's JSC VM's End phase heap-thread until the web worker takes JSLock. (This is not a problem in WebCore since WebCore JSC VM never releases heapAccess. We cannot take the same design since we would like to run End phase even if web worker is not getting any messages). And removing resetJITData in CodeBlock::finalizeUnconditionally does not fix as well since CodeBlock::finalizeUnconditionally calls StructureStubInfo::visitWeakReferences, and it removes some of entries of StructureStubInfo::bufferedStructures after ByVal extension is introduced into StructureStubInfo. This patch uses CacheableIdentifier for bufferedStructures. We make BufferedStructure class which holds Structure and CacheableIdentifier. And StructureStubInfo holds HashSet. We also visit CacheableIdentifier in StructureStubInfo::visitAggregate. To allow concurrent collector to run this, we introduce m_bufferedStructuresLock in StructureStubInfo to guard m_bufferedStructures. * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::StructureStubInfo): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::visitAggregate): (JSC::StructureStubInfo::visitWeakReferences): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): (JSC::StructureStubInfo::getByIdSelfIdentifier): (JSC::StructureStubInfo::cacheType const): (JSC::StructureStubInfo::clearBufferedStructures): (JSC::StructureStubInfo::BufferedStructure::BufferedStructure): (JSC::StructureStubInfo::BufferedStructure::isHashTableDeletedValue const): (JSC::StructureStubInfo::BufferedStructure::hash const): (JSC::StructureStubInfo::BufferedStructure::operator==): (JSC::StructureStubInfo::BufferedStructure::operator!=): (JSC::StructureStubInfo::BufferedStructure::Hash::hash): (JSC::StructureStubInfo::BufferedStructure::Hash::equal): (JSC::StructureStubInfo::BufferedStructure::structure const): (JSC::StructureStubInfo::BufferedStructure::byValId const): * jit/JITOperations.cpp: * runtime/CacheableIdentifier.h: (JSC::CacheableIdentifier::hash const): 2020-03-19 Yusuke Suzuki Unreviewed, build fix after r258717 https://bugs.webkit.org/show_bug.cgi?id=199295 * llint/LowLevelInterpreter.asm: 2020-03-18 Yusuke Suzuki sanitizeStackForVMImpl writes below stack pointer, triggers huge warning spam from valgrind https://bugs.webkit.org/show_bug.cgi?id=199295 Reviewed by Mark Lam. During sanitizeStackForVMImpl, we should not access to the region beyond the stack-pointer. This patch changes stack-pointer while sanitizeStackForVMImpl is zero-filling the old stack region. * llint/LowLevelInterpreter.asm: 2020-03-19 Charlie Turner Fix many warnings with Clang 7.0 on GTK x86-64 in Debug. https://bugs.webkit.org/show_bug.cgi?id=209146 Reviewed by Darin Adler. * runtime/JSCellInlines.h: (JSC::CallFrame::deprecatedVM const): A reference may not be NULL, so this ASSERT() can never trip. 2020-03-18 Yusuke Suzuki Add a way to mark a rejected promise as handled https://bugs.webkit.org/show_bug.cgi?id=209241 Reviewed by Michael Saboff. Some of WebCore promise implementations (WebAnimation etc.) want to reject promise as handled state to suppress UnhandledPromiseRejection tracking. For example, a lot of WebCore implementations expose Promise DOM attributes which will be rejected at some conditions. But we do not want to force users setting a handler for each such an attribute. This patch adds `JSPromise::rejectAsHandled` C++ function. This simply sets isHandledFlag before executing `JSPromise::reject` if we are not calling a reject function yet. * runtime/JSPromise.cpp: (JSC::JSPromise::rejectAsHandled): * runtime/JSPromise.h: * tools/JSDollarVM.cpp: (JSC::functionRejectPromiseAsHandled): (JSC::JSDollarVM::finishCreation): 2020-03-17 Yusuke Suzuki [JSC] DeleteIC patchpoint in FTL should require tag and mask registers https://bugs.webkit.org/show_bug.cgi?id=209197 Reviewed by Tadeu Zagallo and Saam Barati. DeleteIC patchpoint is emitting `branchIfNotCell` machine code. This requires a mask register while we are not reserving them when creating a patchpoint. In general, our IC code is assuming usual CCallHelpers environment which provides macro-assembler scratch, tag, and mask registers. We should offer them even if IC is emitted from FTL. In this patch, we offer tag and mask registers for Delete IC even if this IC is not currently using tag register. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): 2020-03-17 Tadeu Zagallo AccessCase::canReplace should allow a Getter to replace an IntrinsicGetter https://bugs.webkit.org/show_bug.cgi?id=209158 Reviewed by Saam Barati. When we override an intrinsic getter with a user defined getter, we might end up with the same offset and attributes. In which case, an inline cache that contained an entry for the intrisic getter will believe that it is still valid, and add a new getter access case, leading to duplicate entries for the same structure. * bytecode/AccessCase.cpp: (JSC::AccessCase::canReplace const): 2020-03-16 Yusuke Suzuki [JSC] JSMapIterator and JSSetIterator are CellType https://bugs.webkit.org/show_bug.cgi?id=209168 Reviewed by Saam Barati. They are JSCell, not JSObject since they are not used as a user-observable set/map iterators in JSC. However, their JSType is ObjectType. They should use CellType instead. * runtime/JSMapIterator.h: * runtime/JSSetIterator.h: 2020-03-16 Keith Miller JavaScript identifier grammar supports unescaped astral symbols, but JSC doesn’t https://bugs.webkit.org/show_bug.cgi?id=208998 Reviewed by Michael Saboff. This patch fixes a bug in the parser that allows for surrogate pairs when parsing identifiers. It also makes a few other changes to the parser: 1) When looking for keywords we just need to check that subsequent character cannot be a identifier part or an escape start. 2) The only time we call parseIdentifierSlowCase is when we hit an escape start or a surrogate pair so we can optimize that to just copy everything up slow character into our buffer. 3) We shouldn't allow for asking if a UChar is an identifier start/part. * KeywordLookupGenerator.py: (Trie.printSubTreeAsC): (Trie.printAsC): * parser/Lexer.cpp: (JSC::isNonLatin1IdentStart): (JSC::isIdentStart): (JSC::isSingleCharacterIdentStart): (JSC::cannotBeIdentStart): (JSC::isIdentPart): (JSC::isSingleCharacterIdentPart): (JSC::cannotBeIdentPartOrEscapeStart): (JSC::Lexer::currentCodePoint const): (JSC::Lexer::currentCodePoint const): (JSC::Lexer::parseIdentifier): (JSC::Lexer::parseIdentifier): (JSC::Lexer::parseIdentifierSlowCase): (JSC::Lexer::lexWithoutClearingLineTerminator): (JSC::Lexer::scanRegExp): (JSC::isIdentPartIncludingEscapeTemplate): Deleted. (JSC::isIdentPartIncludingEscape): Deleted. * parser/Lexer.h: (JSC::Lexer::setOffsetFromSourcePtr): Deleted. * parser/Parser.cpp: (JSC::Parser::printUnexpectedTokenText): * parser/ParserTokens.h: 2020-03-13 Sergio Villar Senin [WebXR] IDLs, stubs and build configuration for WPE https://bugs.webkit.org/show_bug.cgi?id=208702 Reviewed by Dean Jackson. * Configurations/FeatureDefines.xcconfig: Added ENABLE_WEBXR, off by default. 2020-03-15 Yusuke Suzuki reportZappedCellAndCrash should handle PreciseAllocation in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=209042 Reviewed by Mark Lam. This patch adds support of PreciseAllocation cells to reportZappedCellAndCrash, since now it is frequently used as a lower-tier cells in IsoSubspace. * heap/IsoSubspace.h: * heap/IsoSubspaceInlines.h: (JSC::IsoSubspace::forEachLowerTierFreeListedPreciseAllocation): * runtime/JSCell.cpp: (JSC::reportZappedCellAndCrash): 2020-03-15 Yusuke Suzuki Should not use variable-length-array (VLA) https://bugs.webkit.org/show_bug.cgi?id=209043 Reviewed by Mark Lam. This patch disables variable-length-array (VLA). If this feature uses user-input, user can control the stack height consumed by C++ code. This patch avoids using VLA. To achieve that, 1. We set `-Wvla` warning option to trigger warnings if it is used. 2. Introduce MarkedJSValueRefArray for API. This replaces `JSValueRef arguments[variableLength]` use case. MarkedJSValueRefArray registers itself to JSC GC so that GC can mark it as a strong root. * API/JSContext.mm: (+[JSContext currentArguments]): * API/JSValue.mm: (-[JSValue callWithArguments:]): (-[JSValue constructWithArguments:]): (-[JSValue invokeMethod:withArguments:]): * API/MarkedJSValueRefArray.cpp: Added. (JSC::MarkedJSValueRefArray::MarkedJSValueRefArray): (JSC::MarkedJSValueRefArray::~MarkedJSValueRefArray): (JSC::MarkedJSValueRefArray::visitAggregate): * API/MarkedJSValueRefArray.h: Added. * API/tests/minidom.c: (print): * API/tests/testapi.cpp: (TestAPI::markedJSValueArrayAndGC): (testCAPIViaCpp): * Configurations/Base.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/Heap.cpp: (JSC::Heap::addCoreConstraints): (JSC::Heap::addMarkedJSValueRefArray): * heap/Heap.h: * heap/MarkedSpace.h: (JSC::MarkedSpace::activeWeakSetsBegin): Deleted. (JSC::MarkedSpace::activeWeakSetsEnd): Deleted. (JSC::MarkedSpace::newActiveWeakSetsBegin): Deleted. (JSC::MarkedSpace::newActiveWeakSetsEnd): Deleted. * runtime/ArgList.h: 2020-03-14 Saam Barati Unreviewed. Fix windows build by making configSizeToProtect stay 4KB. * runtime/JSCConfig.h: 2020-03-13 Saam Barati configSizeToProtect should be 16KB https://bugs.webkit.org/show_bug.cgi?id=209068 Reviewed by Keith Miller. * runtime/JSCConfig.h: 2020-03-13 Yusuke Suzuki Unreviewed, fix JSC / test262 tests https://bugs.webkit.org/show_bug.cgi?id=209033 Follow-up change for DisallowGC causes crash because CodeBlock is nullptr when function call is non JS calls. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): 2020-03-13 Tadeu Zagallo Missing arithMode for ArithAbs and ArithNegate in DFGClobberize https://bugs.webkit.org/show_bug.cgi?id=208685 Reviewed by Saam Barati. In the pure case of ArithNegate and ArithAbs in DFGClobberize, their PureValues did not include their respective ArithMode. That means that e.g. a CheckOverflow ArithNegate/Abs could be considered equivalent to an Unchecked version of the same node. Thanks to Samuel Groß of Google Project Zero for identifying this bug. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2020-03-13 Myles C. Maxfield [Cocoa] Push applicationSDKVersion() down from WebCore into WTF https://bugs.webkit.org/show_bug.cgi?id=209030 Reviewed by Simon Fraser. dyld_get_program_sdk_version() gives you the wrong answer in the Web Process (or at least not the answer you actually want). There are already facilities for the UI Process to tell the Web Process what the real value is, but those functions are currently in WebCore, which is inaccessible to WTF. This patch is in preparation for https://bugs.webkit.org/show_bug.cgi?id=208969 which needs to know this information in WTF. I also found a few places which were calling dyld_get_program_sdk_version() in JavaScriptCore and WebCore (which is wrong because those libraries exist in the Web Process), and have fixed them up to use applicationSDKVersion() instead. * API/JSWrapperMap.mm: (supportsInitMethodConstructors): 2020-03-13 Yusuke Suzuki [JSC] Reload CodeBlock or suppress GC while setting up calls https://bugs.webkit.org/show_bug.cgi?id=209033 Reviewed by Saam Barati. The sequence of Interpreter::execute is the following. 1. Getting CodeBlock from Executable 2. Doing a lot of setups 3. Setting (1)'s CodeBlock to ProtoFrame 4. Calling code through Executable During (2), it would be possible that GC happens and it replaces CodeBlock in Executable. Then, when executing JITCode with CodeBlock in (4), we use new JITCode with old CodeBlock. In this patch, For ProgramExecutable, FunctionExecutable, ModuleProgramExecutable, we ensure that no GC happens after getting CodeBlock by placing DisallowGC. For EvalExecutable, we reload CodeBlock after setting up environment. It is possible that FunctionExecutable* stored in CodeBlock can be different when executing a new CodeBlock, but this is OK since this different does not appear and we do not rely on this: we are touching `name` of FunctionExecutable* which is retrieved from CodeBlock. But this name will not be changed since this is derived from UnlinkedFunctionExecutable which is shared by multiple CodeBlocks. And FunctionExecutable* generation ordering must be the same for every CodeBlock generation from the same UnlinkedCodeBlock. * bytecode/CodeBlock.h: (JSC::ScriptExecutable::prepareForExecution): * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): * interpreter/InterpreterInlines.h: (JSC::Interpreter::execute): * runtime/DisallowScope.h: (JSC::DisallowScope::disable): * runtime/StringPrototype.cpp: 2020-03-12 Yusuke Suzuki [JSC] Delete IC creation should check mayNeedToCheckCell/canCacheDeleteIC regardless of Structure::outOfLineCapacity https://bugs.webkit.org/show_bug.cgi?id=209027 Reviewed by Saam Barati. Delete IC code generation assumes that mayNeedToCheckCell (it is replaced with canCacheDeleteIC) is false while we are looking into this status only if Structure::outOfLineCapacity meets a certain condition. We should avoid create Delete IC when mayNeedToCheckCell/canCacheDeleteIC is true regardless of Structure::outOfLineCapacity * bytecode/AccessCase.cpp: (JSC::AccessCase::createDelete): (JSC::AccessCase::generateImpl): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::mayHaveIndexingHeader const): (JSC::Structure::canCacheDeleteIC const): 2020-03-13 Alexey Shvayka Bound functions should pass correct NewTarget value https://bugs.webkit.org/show_bug.cgi?id=209057 Reviewed by Keith Miller. This change implements steps 5-6 of bound function's [[Construct]] method [1], fixing bound function subclasses and aligning JSC with V8 and SpiderMonkey. [1]: https://tc39.es/ecma262/#sec-bound-function-exotic-objects-construct-argumentslist-newtarget * runtime/JSBoundFunction.cpp: (JSC::boundThisNoArgsFunctionConstruct): (JSC::boundFunctionConstruct): 2020-03-13 Yusuke Suzuki Unreviewed, change ASSERT to ASSERT_WITH_SECURITY_IMPLICATION since it is now enabled under ENABLE(SECURITY_ASSERTIONS) https://bugs.webkit.org/show_bug.cgi?id=209041 * runtime/JSCast.h: (JSC::jsCast): 2020-03-12 Yusuke Suzuki Report crashed cell in jsCast in debug builds https://bugs.webkit.org/show_bug.cgi?id=209041 Reviewed by Mark Lam. To collect more information when crashing with jsCast, we attempt to use reportZappedCellAndCrash. If it succeeds, we can get more information in registers. We enable this only for ASSERT_ENABLED build. For non ASSERT_ENABLED, we keep the original assertion since this assertion can be enabled via ENABLE(SECURITY_ASSERTIONS). * heap/SlotVisitor.cpp: (JSC::SlotVisitor::appendToMarkStack): (JSC::SlotVisitor::visitChildren): (JSC::SlotVisitor::reportZappedCellAndCrash): Deleted. * heap/SlotVisitor.h: * runtime/JSCast.h: (JSC::jsCast): * runtime/JSCell.cpp: (JSC::reportZappedCellAndCrash): * runtime/JSCell.h: 2020-03-12 Keith Miller DFG nodes that take a TypedArray's storage need to keepAlive the TypedArray https://bugs.webkit.org/show_bug.cgi?id=209035 Reviewed by Saam Barati. It might be possible to produce a graph where the last reference to a TypedArray is via a GetByVal or PutByVal. Since those nodes don't create any reference to the TypedArray in B3 we may end up not keeping the TypedArray alive until after the storage access. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): 2020-03-12 Yusuke Suzuki [JSC] Use CacheableIdentifier in ByValInfo https://bugs.webkit.org/show_bug.cgi?id=208978 Reviewed by Saam Barati. CodeBlock::finalizeUnconditionally discards JITData. And this includes ByValInfo, which holds Identifier. However, finalizeUnconditionally is only guaranteeing that the main thread is not working. It can be invoked in the heap thread, and it is not not setting the AtomStringTable for this heap thread. If Identifier destroys AtomStringImpl, which fails to unregister itself from the table. In this patch, 1. We explicitly set nullptr for the current AtomStringTable to catch the bug as soon as possible in GC end phase. 2. We use CacheableIdentifier in ByValInfo to avoid destroying Identifier in CodeBlock::finalizeUnconditionally. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/ByValInfo.cpp: Added. (JSC::ByValInfo::visitAggregate): * bytecode/ByValInfo.h: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::stronglyVisitStrongReferences): * bytecode/CodeBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handlePutByVal): * heap/Heap.cpp: (JSC::Heap::runEndPhase): * jit/JIT.h: * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitByValIdentifierCheck): * runtime/CacheableIdentifier.h: 2020-03-11 Keith Miller Test262-runner should always consider crashes as new failures https://bugs.webkit.org/show_bug.cgi?id=208943 Reviewed by Yusuke Suzuki. BigInt.asUintN() / BigInt.asIntN() should not crash when called even if we have not implemented them yet... * runtime/BigIntConstructor.cpp: (JSC::bigIntConstructorFuncAsUintN): (JSC::bigIntConstructorFuncAsIntN): 2020-03-11 Keith Miller Throws incorrectly a syntax error when declaring a top level catch variable the same as a parameter https://bugs.webkit.org/show_bug.cgi?id=189914 Reviewed by Saam Barati. When we are parsing catch block parameters we should increment the statement depth so we don't think we are trying to shadow top level lexical variables in the same statement depth. * parser/Parser.cpp: (JSC::Parser::parseTryStatement): 2020-03-10 Yusuke Suzuki [JSC] Fix iso-subspace static_assert for JSJavaScriptCallFramePrototype https://bugs.webkit.org/show_bug.cgi?id=208874 Reviewed by Saam Barati. This static_assert should ensure the condition for JSJavaScriptCallFramePrototype, not for JSInjectedScriptHostPrototype. * inspector/JSJavaScriptCallFramePrototype.h: 2020-03-09 Don Olmstead Remove obsolete feature flags https://bugs.webkit.org/show_bug.cgi?id=208830 Reviewed by Alex Christensen. Remove ENABLE_CUSTOM_SCHEME_HANDLER and ENABLE_MAC_VIDEO_TOOLBOX since they are no longer used. * Configurations/FeatureDefines.xcconfig: 2020-03-09 Alexey Shvayka @putByValDirect does not perform [[DefineOwnProperty]] correctly https://bugs.webkit.org/show_bug.cgi?id=208708 Reviewed by Yusuke Suzuki. This change adds inSparseIndexingMode() check to canDoFastPutDirectIndex(), fixing slow path of @putByValDirect() to perform [[DefineOwnProperty]] according to spec [1] and aligning JSC with V8 and SpiderMonkey. This patch preserves existing behavior for Arguments exotic objects (thus the checks order) and aligns slow path checks in JSObject::putDirectIndexSlowOrBeyondVectorLength with JSObject::defineOwnIndexedProperty. JetStream2 benchmark is neutral. [1]: https://tc39.es/ecma262/#sec-validateandapplypropertydescriptor * runtime/JSObject.cpp: (JSC::canDoFastPutDirectIndex): 2020-03-09 Antoine Quint Remove the compile-time flag for Pointer Events https://bugs.webkit.org/show_bug.cgi?id=208821 Reviewed by Dean Jackson. * Configurations/FeatureDefines.xcconfig: 2020-03-09 Caio Lima Tail calls are broken on ARM_THUMB2 and MIPS https://bugs.webkit.org/show_bug.cgi?id=197797 Reviewed by Yusuke Suzuki. `prepareForTailCall` operation expects that header size + parameters size is aligned with stack (alignment is 16-bytes for every architecture). This means that headerSizeInBytes + argumentsIncludingThisInBytes needs to be multiple of 16. This was not being preserved during getter IC code for 32-bits. The code generated was taking in account only headerSizeInRegisters (it is 4 on 32-bits) and argumentsIncludingThis (that is always 1 for getters) and allocating 32-bytes when applying operation `(headerSize + argumentsIncludingThis) * 8 - sizeof(CallerFrameAndPC)`. This results in a stack frame with size of 40 bytes (after we push `lr` and `sp`). Since `prepareForTailCall` expects frames to be 16-bytes aligned, it will then calculate the top of such frame considering it is 48 bytes, cloberring values of previous frame and causing unexpected behavior. This patch is fixing how this IC code calculates the stack frame using `roundArgumentCountToAlignFrame(numberOfParameters)` aligning with what we do on code without IC installed. This was not a problem for getter and setter IC on 64-bits because `roundArgumentCountToAlignFrame(1) == 1` and `roundArgumentCountToAlignFrame(2) == 3` while it is `roundArgumentCountToAlignFrame(1) == 2` and `roundArgumentCountToAlignFrame(2) == 2` for MIPS and ARMv7. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): 2020-03-08 Brady Eidson Remember completed subranges during incremental PDF loading. https://bugs.webkit.org/show_bug.cgi?id=208785 Reviewed by Tim Horton. Move 'using WTF::Range' from the WTF/Range.h header to these JSC users. The alternative to making these 3 changes was to make over 20 changes up in the WebCore/WebKits to resolve the conflict with WebCore::Range. * b3/B3HeapRange.h: * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * heap/JITStubRoutineSet.h: 2020-03-07 Alexey Shvayka REGRESSION (r258049): Unchecked JS exception in jsc::Stringifier::toJSON https://bugs.webkit.org/show_bug.cgi?id=208766 Reviewed by Yusuke Suzuki. * runtime/JSONObject.cpp: (JSC::Stringifier::toJSON): Add missing RELEASE_AND_RETURN. 2020-03-07 Mark Lam Remove bad assertion in FTLLowerDFGToB3's compileDelBy(). https://bugs.webkit.org/show_bug.cgi?id=208764 Reviewed by Keith Miller. The assertion ASSERT(base.gpr() != params[2].gpr()) is wrong because it is legal JS to pass in the same value as the base and subscript. The runtime will handle it properly. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): 2020-03-05 Sam Weinig Move JavaScriptCore related feature defines from FeatureDefines.xcconfig to PlatformEnableCocoa.h https://bugs.webkit.org/show_bug.cgi?id=207436 Reviewed by Darin Adler. * Configurations/FeatureDefines.xcconfig: Remove JSC related defines. 2020-03-06 Yusuke Suzuki [JSC] Enable public class fields https://bugs.webkit.org/show_bug.cgi?id=208756 Reviewed by Mark Lam. This patch turns public-class-fields feature on, implemented in r254653. To separate from private-class-fields, this patch renames the flag from useClassFields to usePublicClassFields, and first enable public-class-fields feature. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallValueNode::emitBytecode): * parser/Parser.cpp: (JSC::Parser::parseClass): * runtime/OptionsList.h: 2020-03-06 Mark Lam Add "AndOrdered" to the names of ordered DoubleConditions. https://bugs.webkit.org/show_bug.cgi?id=208736 Reviewed by Keith Miller. Renamed the following: DoubleEqual ==> DoubleEqualAndOrdered DoubleNotEqual ==> DoubleNotEqualAndOrdered DoubleGreaterThan ==> DoubleGreaterThanAndOrdered DoubleGreaterThanOrEqual ==> DoubleGreaterThanOrEqualAndOrdered DoubleLessThan ==> DoubleLessThanAndOrdered DoubleLessThanOrEqual ==> DoubleLessThanOrEqualAndOrdered The comment for these enums in MacroAssemblerARM64.h says: // These conditions will only evaluate to true if the comparison is ordered - i.e. neither operand is NaN. Adding "AndOrdered" to their names makes this property explicit. From reading the original names, one might intuitively think that these conditions map directly to the C++ double comparisons. This intuition is incorrect. Consider the DoubleNotEqual case: let's compare 2 doubles, a and b: result = (a != b); For C++, if either a or b are NaNs, then a != b will actually return true. This is contrary to the behavior documented in the MacroAssemblerARM64.h comment above about how DoubleNotEqual should behave. In our code, DoubleNotEqual actually means DoubleNotEqualAndOrdered. The C++ != behavior actually matches our DoubleNotEqualOrUnordered condition instead. The tendency to want to associate DoubleNotEqual with the behavior of the C++ != operator is precisely why we should give these conditions better names. Adding the "AndOperand" name make the expected behavior explicit in the name, and leave no room for confusion with C++ double comparison semantics. * assembler/MacroAssembler.cpp: (WTF::printInternal): * assembler/MacroAssembler.h: (JSC::MacroAssembler::invert): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare): (JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare): (JSC::MacroAssemblerARM64::jumpAfterFloatingPointCompare): (JSC::MacroAssemblerARM64::floatingPointCompare): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchDouble): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchDouble): (JSC::MacroAssemblerMIPS::branchDoubleNonZero): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::branchDoubleNonZero): (JSC::MacroAssemblerX86Common::moveConditionallyDouble): (JSC::MacroAssemblerX86Common::invert): (JSC::MacroAssemblerX86Common::floatingPointCompare): (JSC::MacroAssemblerX86Common::jumpAfterFloatingPointCompare): (JSC::MacroAssemblerX86Common::moveConditionallyAfterFloatingPointCompare): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::truncateDoubleToUint64): (JSC::MacroAssemblerX86_64::truncateFloatToUint64): * assembler/testmasm.cpp: (JSC::testCompareDouble): (JSC::testCompareDoubleSameArg): (JSC::testMoveConditionallyFloatingPoint): (JSC::testMoveDoubleConditionallyDouble): (JSC::testMoveDoubleConditionallyDoubleDestSameAsThenCase): (JSC::testMoveDoubleConditionallyDoubleDestSameAsElseCase): (JSC::testMoveDoubleConditionallyFloat): (JSC::testMoveDoubleConditionallyFloatDestSameAsThenCase): (JSC::testMoveDoubleConditionallyFloatDestSameAsElseCase): (JSC::testMoveConditionallyFloatingPointSameArg): (JSC::run): * b3/B3LowerToAir.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::compileClampDoubleToByte): (JSC::DFG::SpeculativeJIT::compileArithRounding): (JSC::DFG::SpeculativeJIT::compileArithMinMax): (JSC::DFG::SpeculativeJIT::compileArithPow): (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNumberIsInteger): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfNotNaN): * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_jless): (JSC::JIT::emitSlow_op_jlesseq): (JSC::JIT::emitSlow_op_jgreater): (JSC::JIT::emitSlow_op_jgreatereq): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): * jit/ThunkGenerators.cpp: (JSC::floorThunkGenerator): (JSC::roundThunkGenerator): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): 2020-03-06 David Kilzer REGRESSION (r258038): Build failure on Windows 10 bots * assembler/testmasm.cpp: (JSC::testCompareDouble): (JSC::testCompareDoubleSameArg): (JSC::testMoveConditionallyFloatingPoint): (JSC::testMoveConditionallyFloatingPointSameArg): - Add RELEASE_ASSERT_NOT_REACHED() statements to try to fix the bots. 2020-03-06 Yusuke Suzuki Put remaining fixed-sized cells into IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=208754 Reviewed by Keith Miller. Put remaining fixed-sized cells into IsoSubspace. Now all the fixed-sized cells have their own IsoSubspaces. 1. JSArray (We need to care about RAMification number, or compensate RAMification regression with improvements). 2. Inspector's objects 3. All prototype objects have one IsoSubspace since they are plain objects. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::JSInjectedScriptHost): * inspector/JSInjectedScriptHost.h: * inspector/JSInjectedScriptHostPrototype.h: * inspector/JSJavaScriptCallFrame.cpp: (Inspector::JSJavaScriptCallFrame::JSJavaScriptCallFrame): * inspector/JSJavaScriptCallFrame.h: * inspector/JSJavaScriptCallFramePrototype.h: * jsc.cpp: (JSC::Masquerader::subspaceFor): (JSCMemoryFootprint::subspaceFor): * runtime/ArrayIteratorPrototype.h: * runtime/ArrayPrototype.h: * runtime/AsyncFromSyncIteratorPrototype.h: * runtime/AsyncFunctionPrototype.h: * runtime/AsyncGeneratorFunctionPrototype.h: * runtime/AsyncGeneratorPrototype.h: * runtime/AsyncIteratorPrototype.h: * runtime/AtomicsObject.h: * runtime/BigIntPrototype.h: * runtime/ConsoleObject.h: * runtime/DatePrototype.h: * runtime/ErrorPrototype.h: * runtime/ExceptionHelpers.h: * runtime/GeneratorFunctionPrototype.h: * runtime/GeneratorPrototype.h: * runtime/InspectorInstrumentationObject.h: * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormatPrototype.h: * runtime/IntlObject.h: * runtime/IntlPluralRulesPrototype.h: * runtime/IteratorPrototype.h: * runtime/JSArray.h: (JSC::JSArray::subspaceFor): * runtime/JSArrayBufferPrototype.h: * runtime/JSDataViewPrototype.h: * runtime/JSDestructibleObject.h: (JSC::JSDestructibleObject::subspaceFor): Deleted. * runtime/JSGenericTypedArrayViewPrototype.h: * runtime/JSModuleLoader.h: * runtime/JSONObject.h: * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSFinalObject::subspaceFor): (JSC::JSObject::subspaceFor): Deleted. * runtime/JSPromisePrototype.h: (JSC::JSPromisePrototype::subspaceFor): * runtime/JSTypedArrayViewPrototype.h: * runtime/MapIteratorPrototype.h: * runtime/MapPrototype.h: * runtime/MathObject.h: * runtime/NativeErrorPrototype.h: * runtime/ObjectPrototype.h: * runtime/ReflectObject.h: * runtime/RegExpPrototype.h: * runtime/RegExpStringIteratorPrototype.h: * runtime/SetIteratorPrototype.h: * runtime/SetPrototype.h: * runtime/StringIteratorPrototype.h: * runtime/SymbolPrototype.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/WeakMapPrototype.h: * runtime/WeakObjectRefPrototype.h: * runtime/WeakSetPrototype.h: * tools/JSDollarVM.cpp: * tools/JSDollarVM.h: * wasm/js/JSWebAssembly.h: * wasm/js/WebAssemblyCompileErrorPrototype.h: * wasm/js/WebAssemblyGlobalPrototype.h: * wasm/js/WebAssemblyInstancePrototype.h: * wasm/js/WebAssemblyLinkErrorPrototype.h: * wasm/js/WebAssemblyMemoryPrototype.h: * wasm/js/WebAssemblyModulePrototype.h: * wasm/js/WebAssemblyRuntimeErrorPrototype.h: * wasm/js/WebAssemblyTablePrototype.h: 2020-03-06 Alexey Shvayka JSON.stringify should call replacer on deleted properties https://bugs.webkit.org/show_bug.cgi?id=208725 Reviewed by Ross Kirsling. This change removes extra `hasProperty` check from `appendNextProperty` as it does not exist in the spec [1], aligning JSC with V8 and SpiderMonkey. This patch also replaces 3 usages of `getPropertySlot` with semantically equivalent (yet more concise) `get` and inlines `toJSONImpl` (this change is performance-neutral). [1]: https://tc39.es/ecma262/#sec-serializejsonobject (steps 6, 8.a) * runtime/JSONObject.cpp: (JSC::Stringifier::toJSON): (JSC::Stringifier::Holder::appendNextProperty): (JSC::Stringifier::toJSONImpl): Deleted. 2020-03-06 Mark Lam Fix some issues in the ARM64 moveConditionallyAfterFloatingPointCompare() and moveDoubleConditionallyAfterFloatingPointCompare(). https://bugs.webkit.org/show_bug.cgi?id=208731 Reviewed by Saam Barati. Both the ARM64 moveConditionallyAfterFloatingPointCompare() and moveDoubleConditionallyAfterFloatingPointCompare() had the following issues: 1. For the DoubleNotEqual condition, they fail to set the result register if one or both of the comparison operands is a NaN. 2. For the DoubleEqualOrUnordered condition, they can clobber the else case input register if one of the comparison operands is a NaN. This patch fixes both of these, and exhaustive testmasm test cases for affected MacroAssembler instruction emitters using these functions. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare): (JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare): * assembler/testmasm.cpp: (JSC::testCompareDouble): (JSC::testCompareDoubleSameArg): (JSC::testMoveConditionallyFloatingPoint): (JSC::testMoveConditionallyDouble2): (JSC::testMoveConditionallyDouble3): (JSC::testMoveConditionallyDouble3DestSameAsThenCase): (JSC::testMoveConditionallyDouble3DestSameAsElseCase): (JSC::testMoveConditionallyFloat2): (JSC::testMoveConditionallyFloat3): (JSC::testMoveConditionallyFloat3DestSameAsThenCase): (JSC::testMoveConditionallyFloat3DestSameAsElseCase): (JSC::testMoveDoubleConditionallyDouble): (JSC::testMoveDoubleConditionallyDoubleDestSameAsThenCase): (JSC::testMoveDoubleConditionallyDoubleDestSameAsElseCase): (JSC::testMoveDoubleConditionallyFloat): (JSC::testMoveDoubleConditionallyFloatDestSameAsThenCase): (JSC::testMoveDoubleConditionallyFloatDestSameAsElseCase): (JSC::testMoveConditionallyFloatingPointSameArg): (JSC::testMoveConditionallyDouble2SameArg): (JSC::testMoveConditionallyDouble3SameArg): (JSC::testMoveConditionallyFloat2SameArg): (JSC::testMoveConditionallyFloat3SameArg): (JSC::testMoveDoubleConditionallyDoubleSameArg): (JSC::testMoveDoubleConditionallyFloatSameArg): (JSC::run): 2020-03-05 Paulo Matos [JSCOnly] 32-bits warning on memset of JSValue https://bugs.webkit.org/show_bug.cgi?id=204411 Reviewed by Mark Lam. Fixes warning on 32bit builds. This is required because GCC knows it is not safe to use memset on non-POD types and warns against its use. * heap/GCMemoryOperations.h: (JSC::gcSafeZeroMemory): 2020-03-04 Mark Lam Handle an out of memory error while constructing the BytecodeGenerator. https://bugs.webkit.org/show_bug.cgi?id=208622 Reviewed by Saam Barati. Added the ability to handle out of memory errors encountered during the construction of the BytecodeGenerator. Currently, we only use this for the case where we fail to instantiate a ScopedArgumentsTable. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGeneratorBase.h: * runtime/ScopedArgumentsTable.cpp: (JSC::ScopedArgumentsTable::tryCreate): * runtime/ScopedArgumentsTable.h: * runtime/SymbolTable.h: 2020-03-04 Paulo Matos JSC 32bits broken in debug mode by r257399 https://bugs.webkit.org/show_bug.cgi?id=208439 Reviewed by Carlos Alberto Lopez Perez. Use uses() method call instead of gpr() on assert to that it works for both 64 and 32 bits. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): 2020-03-03 Saam Barati Refactor FixedVMPoolExecutableAllocator to not have member functions which are really just helper functions https://bugs.webkit.org/show_bug.cgi?id=208537 Reviewed by Mark Lam. There were a few member functions in FixedVMPoolExecutableAllocator that were essentially helper functions. I've factored them out, and made FixedVMPoolExecutableAllocator call them directly. This refactoring is needed when I implement the 1GB executable pool on arm64 since the implementation of that will create split implementations of something like FixedVMPoolExecutableAllocator. * jit/ExecutableAllocator.cpp: (JSC::jitWriteThunkGenerator): (JSC::genericWriteToJITRegion): (JSC::initializeSeparatedWXHeaps): (JSC::initializeJITPageReservation): (JSC::ExecutableAllocator::isValid const): (JSC::ExecutableAllocator::underMemoryPressure): (JSC::ExecutableAllocator::memoryPressureMultiplier): (JSC::ExecutableAllocator::allocate): (JSC::ExecutableAllocator::isValidExecutableMemory): (JSC::ExecutableAllocator::getLock const): (JSC::ExecutableAllocator::committedByteCount): (JSC::ExecutableAllocator::dumpProfile): (JSC::startOfFixedExecutableMemoryPoolImpl): (JSC::endOfFixedExecutableMemoryPoolImpl): (JSC::isJITPC): 2020-03-03 Ross Kirsling Introduce JSRemoteInspectorServerStart API for socket-based RWI. https://bugs.webkit.org/show_bug.cgi?id=208349 Reviewed by Joseph Pecoraro. * API/JSRemoteInspectorServer.cpp: Added. (JSRemoteInspectorServerStart): * API/JSRemoteInspectorServer.h: Added. * CMakeLists.txt: 2020-03-03 Basuke Suzuki [WinCairo][PlayStation] Add interface to get listening port of RemoteInspectorServer https://bugs.webkit.org/show_bug.cgi?id=208391 Reviewed by Don Olmstead. When passing zero as a port argument, system will pick an available port for it. Without this method, client cannot get which port is listening. * inspector/remote/socket/RemoteInspectorServer.cpp: (Inspector::RemoteInspectorServer::start): (Inspector::RemoteInspectorServer::getPort): * inspector/remote/socket/RemoteInspectorServer.h: 2020-03-03 Yusuke Suzuki [JSC] @hasOwnLengthProperty returns wrong value if "length" is attempted to be modified https://bugs.webkit.org/show_bug.cgi?id=208497 Reviewed by Mark Lam. When "length" of JSFunction is attempted to be modified, we put a flag. And @hasOwnLengthProperty does not correctly use this flag to return a value for the fast path. This affects on "length" property of bound functions. For example, function userFunction(a) { } userFunction.length = 20; // This field is read-only. So, it is not changed. userFunction.bind().length; // Should be 1, but it returns 0. 1. We rename m_hasModifiedLength to m_hasModifiedLengthForNonHostFunction and m_hasModifiedName to m_hasModifiedNameForNonHostFunction since we are not tracking these states for host-functions which can eagerly initialize them. 2. We rename areNameAndLengthOriginal to canAssumeNameAndLengthAreOriginal to allow it to return "false" for host functions. If it returns true, we go to the fast path. 3. Correctly use canAssumeNameAndLengthAreOriginal information in @hasOwnLengthProperty. * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::FunctionRareData): * runtime/FunctionRareData.h: * runtime/JSFunction.cpp: (JSC::JSFunction::put): (JSC::JSFunction::deleteProperty): (JSC::JSFunction::defineOwnProperty): * runtime/JSFunction.h: * runtime/JSFunctionInlines.h: (JSC::JSFunction::canAssumeNameAndLengthAreOriginal): (JSC::JSFunction::areNameAndLengthOriginal): Deleted. * runtime/JSGlobalObject.cpp: (JSC::hasOwnLengthProperty): * tools/JSDollarVM.cpp: (JSC::functionHasOwnLengthProperty): 2020-03-02 Alan Coon Add new Mac target numbers https://bugs.webkit.org/show_bug.cgi?id=208398 Reviewed by Alexey Proskuryakov. * Configurations/Base.xcconfig: * Configurations/DebugRelease.xcconfig: * Configurations/Version.xcconfig: * Configurations/WebKitTargetConditionals.xcconfig: 2020-03-02 Justin Michaud Delete by val caching does not keep the subscript alive https://bugs.webkit.org/show_bug.cgi?id=208393 Reviewed by Yusuke Suzuki. Before, the provided test case crashed with asan because we did not keep deleteByVal subscripts alive. This patch changes CacheableIdentifier to make this mistake harder to make again, by making the constructor calls more explicit when CacheableIdentifier will not keep an Identifier alive. * jit/JITOperations.cpp: * jit/Repatch.cpp: (JSC::tryCachePutByID): (JSC::tryCacheDeleteBy): (JSC::repatchDeleteBy): (JSC::tryCacheInByID): (JSC::tryCacheInstanceOf): (JSC::tryCacheDelBy): Deleted. (JSC::repatchDelBy): Deleted. * jit/Repatch.h: * runtime/CacheableIdentifier.h: * runtime/CacheableIdentifierInlines.h: (JSC::CacheableIdentifier::createFromIdentifierOwnedByCodeBlock): (JSC::CacheableIdentifier::createFromCell): 2020-03-02 Paulo Matos Fix JSC 32bit alignment increase gcc warning https://bugs.webkit.org/show_bug.cgi?id=208445 Reviewed by Yusuke Suzuki. Use reinterpret_cast_ptr<>() instead of reinterpret_cast<>() to avoid GCC warning about increase in alignment requirement for cast target type. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileExit): 2020-03-02 Yusuke Suzuki Unreviewed, fix wrong assertion https://bugs.webkit.org/show_bug.cgi?id=208404 * runtime/CachedTypes.cpp: (JSC::CachedUniquedStringImplBase::decode const): 2020-03-01 Charles Turner undefined reference to `JSC::ExecutableBase::hasJITCodeForCall() const' https://bugs.webkit.org/show_bug.cgi?id=207890 Reviewed by Yusuke Suzuki. Encountered on arm-buildroot-linux-gnueabihf with GCC 9.2.0. * runtime/NativeExecutable.cpp: Inclusion of ExecutableBaseInlines.h resolves the issue for me. 2020-02-29 Yusuke Suzuki Remove std::lock_guard https://bugs.webkit.org/show_bug.cgi?id=206451 Reviewed by Anders Carlsson. * API/JSVirtualMachine.mm: (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): * API/glib/JSCVirtualMachine.cpp: (addWrapper): (removeWrapper): * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::analyzeNode): (JSC::HeapSnapshotBuilder::analyzeEdge): (JSC::HeapSnapshotBuilder::analyzePropertyNameEdge): (JSC::HeapSnapshotBuilder::analyzeVariableNameEdge): (JSC::HeapSnapshotBuilder::analyzeIndexEdge): (JSC::HeapSnapshotBuilder::setOpaqueRootReachabilityReasonForCell): * heap/MachineStackMarker.cpp: (JSC::MachineThreads::tryCopyOtherThreadStacks): * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::timerDidFire): 2020-02-28 Yusuke Suzuki [JSC] BuiltinNames' HashMap should be small https://bugs.webkit.org/show_bug.cgi?id=208404 Reviewed by Mark Lam. This patch converts public-to-private-name-map from HashMap, SymbolImpl*> to HashSet to save half of memory. The key is that private names have the same string content to the public names. We can just query with string content to the HashSet of private names, and we can get private names. The problem is that we also have a hack inserting string <-> non-private well-known Symbol mappings into this table. These symbols do not have the same content to the public string. So the above assumption is broken. To make the above assumption valid, we have a separate small HashMap which holds string <-> non-private well-known Symbol mappings. Since # of well-known Symbols are only 13, this new HashMap is taking at most 512B for entries, which is much smaller compared to the saved memory by converting HashMap to HashSet for private names (32KB). To allow it, we introduce new well-known Symbol identifier syntax to builtin JS, which is "@@iterator" format. If there is two "@", we parse this identifier as a well-known Symbol. * builtins/ArrayConstructor.js: (from.wrapper.iterator): (from): (from.wrapper.iteratorSymbol): Deleted. * builtins/ArrayPrototype.js: (globalPrivate.concatSlowPath): (concat): * builtins/BuiltinNames.cpp: (JSC::BuiltinNames::BuiltinNames): (JSC::CharBufferSeacher::hash): (JSC::CharBufferSeacher::equal): (JSC::lookUpPrivateNameImpl): (JSC::lookUpWellKnownSymbolImpl): (JSC::BuiltinNames::lookUpPrivateName const): (JSC::BuiltinNames::lookUpWellKnownSymbol const): * builtins/BuiltinNames.h: (JSC::BuiltinNames::lookUpPrivateName const): (JSC::BuiltinNames::lookUpWellKnownSymbol const): (JSC::BuiltinNames::checkPublicToPrivateMapConsistency): (JSC::BuiltinNames::appendExternalName): (JSC::BuiltinNames::getPublicName const): Deleted. * builtins/GlobalOperations.js: (globalPrivate.speciesConstructor): * builtins/IteratorHelpers.js: (performIteration): * builtins/StringPrototype.js: (match): (matchAll): (intrinsic.StringPrototypeReplaceIntrinsic.replace): (replaceAll): (search): (split): * builtins/TypedArrayConstructor.js: (from.wrapper.iterator): (from): (from.wrapper.iteratorSymbol): Deleted. * builtins/TypedArrayPrototype.js: (globalPrivate.typedArraySpeciesConstructor): (map): (filter): * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirectPrivate): (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirectPrivate): * parser/Lexer.cpp: (JSC::Lexer::parseIdentifier): (JSC::Lexer::parseIdentifier): * runtime/CachedTypes.cpp: (JSC::CachedUniquedStringImplBase::encode): (JSC::CachedUniquedStringImplBase::decode const): * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): (JSC::CommonIdentifiers::lookUpPrivateName const): Deleted. (JSC::CommonIdentifiers::getPublicName const): Deleted. * runtime/CommonIdentifiers.h: * tools/JSDollarVM.cpp: (JSC::functionGetPrivateProperty): 2020-02-28 Saam Barati Clean up code with how we choose Gigacage sizes and whether or not to use Wasm fast memory https://bugs.webkit.org/show_bug.cgi?id=208392 Reviewed by Yusuke Suzuki. * runtime/OptionsList.h: 2020-02-27 Saam Barati Fix debug arm64 Wasm tests https://bugs.webkit.org/show_bug.cgi?id=208362 Reviewed by Yusuke Suzuki. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::emitChecksForModOrDiv): We were assuming that "-1" is a valid imm on arm64, but it's not, we need to use big imm. 2020-02-27 Justin Michaud Poly proto should work with property delete transitions https://bugs.webkit.org/show_bug.cgi?id=208261 Reviewed by Saam Barati. This patch fixes a bug where the combination of inline caching and poly proto cause us to cache a setter call along a prototype chain that is no longer the correct setter to call. This is exposed as a result of https://bugs.webkit.org/show_bug.cgi?id=206430 since DefineOwnProperty used to transition to uncacheable dictionary. The case looks like this: A - setter for x redefines x | B | C We set (new C).x Right now, we first call A's setter, then we try to figure out what the state of things were before it was called in order to cache it. We just assume that A's setter still exists, and we cache it without ever checking, In this patch, we ensure that the property exists and the attributes match in order to prevent crashing. In the code, A = target, C = base. Get is correct because it collects caching information before any calls. The bug https://bugs.webkit.org/show_bug.cgi?id=208337 tracks the remaining semantic bugs around this code. * jit/Repatch.cpp: (JSC::tryCachePutByID): 2020-02-27 Basuke Suzuki [WinCairo] Fix RemoteInspector reconnect issue https://bugs.webkit.org/show_bug.cgi?id=208256 Reviewed by Devin Rousso. Call target's disconnection sequence asynchronously to avoid deadlock. * inspector/remote/RemoteConnectionToTarget.cpp: (Inspector::RemoteConnectionToTarget::close): * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: (Inspector::RemoteInspectorSocketEndpoint::workerThread): 2020-02-26 Mark Lam Enhance JSObjectGetProperty() to mitigate against null object pointers. https://bugs.webkit.org/show_bug.cgi?id=208275 Reviewed by Robin Morisset. * API/JSObjectRef.cpp: (JSObjectGetProperty): 2020-02-26 Saam Barati Make testair pass on arm64 https://bugs.webkit.org/show_bug.cgi?id=208258 Reviewed by Tadeu Zagallo. testElideMoveThenRealloc and testElideSimpleMove were never tested on arm64. This patch makes those tests work. - testElideMoveThenRealloc was using a BitImm that is invalid on arm64 - testElideSimpleMove was testing for the wrong disassembly * b3/air/testair.cpp: 2020-02-26 Don Olmstead Allow setting of stack sizes for threads https://bugs.webkit.org/show_bug.cgi?id=208223 Reviewed by Yusuke Suzuki. Specify ThreadType at the Thread::create callsite. * heap/Heap.cpp: (JSC::Heap::notifyIsSafeToCollect): 2020-02-26 Caio Lima [JSC][MIPS] Adding support to Checkpoints https://bugs.webkit.org/show_bug.cgi?id=208196 Reviewed by Yusuke Suzuki. This patch is adding changes to properly support OSR to checkpoints on MIPS. It required fixes on JIT probe and some adjustment on Offlineasm to correct generate `$gp` load when executing `checkpoint_osr_exit_from_inlined_call_trampoline`. * assembler/MacroAssemblerMIPS.cpp: Probe trampoline needs to allocate 16 bytes for 4 arguments to properly follow C calling conventions. This space is used by callee when the JSC is compiled with `-O0` flags (Check "DEFAULT C CALLING CONVENTION (O32)" section on https://www.mips.com/downloads/mips32-instruction-set-quick-reference-v1-01). * llint/LowLevelInterpreter.asm: As we need to do on ARMv7, 64-bits arguments needs to be passed in register pairs `$a1:$a0` or `$a3:$a2` (little-endian mode). Since `$a0` contais `CallFrame*`, we need to pass `EncodedJSValue` on `$a3:$a2` pair. * offlineasm/mips.rb: Following the same reason for return locations on OSR to LLInt, we need to adjust `$gp` using `$ra` instead of `$t9` on `checkpoint_osr_exit_from_inlined_call_trampoline`, given it is only reachable through `ret` operations. For detailed explanation, check ChangeLog of https://trac.webkit.org/changeset/252713. 2020-02-25 Devin Rousso Web Inspector: safari app extension isolated worlds and injected files use the extension's identifier instead of its name https://bugs.webkit.org/show_bug.cgi?id=206911 Reviewed by Brian Burg. * inspector/protocol/Browser.json: Added. Add a `Browser` agent that can communicate with the inspected page's containing browser. It lives in the UIProcess alongside the `Target` agent (meaning there should only be one per debuggable rather than one per target) and as such is not routed through the `Target` agent. * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources.make: 2020-02-25 Justin Michaud Inline Cache delete by id/val https://bugs.webkit.org/show_bug.cgi?id=207522 Reviewed by Keith Miller and Filip Pizlo. We add inline caching for deleteById/val for baseline only. We also fix a concurrency bug in ICStats used for testing. We add three new access cases (no inline code is emitted at this time): - Delete is a cached delete of an existing property - DeleteMiss is a delete of a property that does not exist - DeleteNonConfigurable is a delete of a property that exists, but should not be deleted. There are no conditions required for these caches, since the structure id must change and the prototype does not matter. This gives the following microbenchmark results: delete-property-keeps-cacheable-structure (neutral) delete-property-inline-cache definitely 3.9096x faster delete-property-inline-cache-polymorphic definitely 1.5239x faster delete-property-from-prototype-chain (neutral) * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::deleteProperty): (JSC::JSCallbackObject::deletePropertyByIndex): * API/JSObjectRef.cpp: (JSObjectDeletePropertyForKey): (JSObjectDeleteProperty): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/AccessCase.cpp: (JSC::AccessCase::create): (JSC::AccessCase::createTransition): (JSC::AccessCase::createDelete): (JSC::AccessCase::requiresIdentifierNameMatch const): (JSC::AccessCase::requiresInt32PropertyCheck const): (JSC::AccessCase::needsScratchFPR const): (JSC::AccessCase::forEachDependentCell const): (JSC::AccessCase::doesCalls const): (JSC::AccessCase::canReplace const): (JSC::AccessCase::dump const): (JSC::AccessCase::propagateTransitions const): (JSC::AccessCase::generateImpl): * bytecode/AccessCase.h: (JSC::AccessCase::structure const): (JSC::AccessCase::newStructure const): * bytecode/PolymorphicAccess.cpp: (WTF::printInternal): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::deleteProperty): * debugger/DebuggerScope.h: * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addDelById): (JSC::DFG::JITCompiler::addDelByVal): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDeleteById): Deleted. (JSC::DFG::SpeculativeJIT::compileDeleteByVal): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileDeleteById): (JSC::DFG::SpeculativeJIT::compileDeleteByVal): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileDeleteById): (JSC::DFG::SpeculativeJIT::compileDeleteByVal): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteById): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal): * jit/ICStats.h: * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): (JSC::JIT::link): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITDelByValGenerator::JITDelByValGenerator): (JSC::JITDelByValGenerator::generateFastPath): (JSC::JITDelByValGenerator::finalize): (JSC::JITDelByIdGenerator::JITDelByIdGenerator): (JSC::JITDelByIdGenerator::generateFastPath): (JSC::JITDelByIdGenerator::finalize): * jit/JITInlineCacheGenerator.h: (JSC::JITDelByValGenerator::JITDelByValGenerator): (JSC::JITDelByValGenerator::slowPathJump const): (JSC::JITDelByIdGenerator::JITDelByIdGenerator): (JSC::JITDelByIdGenerator::slowPathJump const): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emitSlow_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emitSlow_op_del_by_val): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emitSlow_op_del_by_val): (JSC::JIT::emitSlow_op_del_by_id): * jit/Repatch.cpp: (JSC::tryCachePutByID): (JSC::tryCacheDelBy): (JSC::repatchDelBy): (JSC::resetPutByID): (JSC::resetDelBy): * jit/Repatch.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CacheableIdentifierInlines.h: (JSC::CacheableIdentifier::CacheableIdentifier): * runtime/ClassInfo.h: * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::deleteProperty): * runtime/ClonedArguments.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/DeletePropertySlot.h: Added. (JSC::DeletePropertySlot::DeletePropertySlot): (JSC::DeletePropertySlot::setConfigurableMiss): (JSC::DeletePropertySlot::setNonconfigurable): (JSC::DeletePropertySlot::setHit): (JSC::DeletePropertySlot::isCacheableDelete const): (JSC::DeletePropertySlot::isDeleteHit const): (JSC::DeletePropertySlot::isConfigurableDeleteMiss const): (JSC::DeletePropertySlot::isNonconfigurable const): (JSC::DeletePropertySlot::cachedOffset const): (JSC::DeletePropertySlot::disableCaching): (JSC::DeletePropertySlot::isCacheable const): * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::deleteProperty): * runtime/ErrorConstructor.h: * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::deleteProperty): * runtime/ErrorInstance.h: * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::put): (JSC::GenericArguments::deleteProperty): * runtime/GetterSetter.h: * runtime/JSArray.cpp: (JSC::JSArray::deleteProperty): * runtime/JSArray.h: * runtime/JSCJSValue.h: * runtime/JSCell.cpp: (JSC::JSCell::deleteProperty): * runtime/JSCell.h: * runtime/JSDataView.cpp: (JSC::JSDataView::deleteProperty): * runtime/JSDataView.h: * runtime/JSFunction.cpp: (JSC::JSFunction::deleteProperty): * runtime/JSFunction.h: * runtime/JSGenericTypedArrayView.h: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::deleteProperty): (JSC::JSGenericTypedArrayView::deletePropertyByIndex): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addFunction): * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::deleteProperty): * runtime/JSLexicalEnvironment.h: * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::deleteProperty): * runtime/JSModuleEnvironment.h: * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::deleteProperty): * runtime/JSModuleNamespaceObject.h: * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): (JSC::JSObject::deletePropertyByIndex): (JSC::validateAndApplyPropertyDescriptor): * runtime/JSObject.h: * runtime/JSProxy.cpp: (JSC::JSProxy::deleteProperty): * runtime/JSProxy.h: * runtime/JSSymbolTableObject.cpp: (JSC::JSSymbolTableObject::deleteProperty): * runtime/JSSymbolTableObject.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::deleteProperty): * runtime/ProxyObject.h: * runtime/RegExpObject.cpp: (JSC::RegExpObject::deleteProperty): * runtime/RegExpObject.h: * runtime/StrictEvalActivation.cpp: (JSC::StrictEvalActivation::deleteProperty): * runtime/StrictEvalActivation.h: * runtime/StringObject.cpp: (JSC::StringObject::deleteProperty): * runtime/StringObject.h: * runtime/Structure.cpp: (JSC::Structure::removePropertyTransition): (JSC::Structure::removePropertyTransitionFromExistingStructureImpl): (JSC::Structure::removePropertyTransitionFromExistingStructure): (JSC::Structure::removePropertyTransitionFromExistingStructureConcurrently): (JSC::Structure::removeNewPropertyTransition): (JSC::Structure::dump const): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::hasIndexingHeader const): (JSC::Structure::mayHaveIndexingHeader const): * tools/JSDollarVM.cpp: (JSC::functionHasOwnLengthProperty): (JSC::JSDollarVM::finishCreation): 2020-02-24 Yusuke Suzuki [WTF] Attach WARN_UNUSED_RETURN to makeScopeExit and fix existing wrong usage https://bugs.webkit.org/show_bug.cgi?id=208162 Reviewed by Robin Morisset. * parser/Parser.cpp: (JSC::Parser::parseUnaryExpression): 2020-02-24 Keith Miller LLInt should fast path for jtrue/false on Symbols and Objects https://bugs.webkit.org/show_bug.cgi?id=208151 Reviewed by Yusuke Suzuki. 64-bit interpreter can fast path the case where an object or symbol is passed to a jtrue or jfalse opcode. This is because these values are always truthy. Also, fix some weird indentation in LowLevelInterpreter.asm. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSType.h: 2020-02-24 Caio Lima [JSC] 32-bits debug build broken after r257212 https://bugs.webkit.org/show_bug.cgi?id=208149 Reviewed by Yusuke Suzuki. Changing `Structure::setCachedPrototypeChain` to use `m_cachedPrototypeChainOrRareData.setMayBeNull`, since `chain` may be null. * runtime/StructureInlines.h: (JSC::Structure::setCachedPrototypeChain): 2020-02-24 Yusuke Suzuki Unreviewed, fix watchOS build https://bugs.webkit.org/show_bug.cgi?id=207827 While watchOS does not use FTL at all, it still compiles. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys): (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::loadStructureClassInfo): (JSC::FTL::DFG::LowerDFGToB3::loadStructureCachedPrototypeChainOrRareData): 2020-02-24 Yusuke Suzuki Unreviewed, build fix for 32bit pointer architectures https://bugs.webkit.org/show_bug.cgi?id=207827 * runtime/Structure.h: 2020-02-23 Yusuke Suzuki [JSC] Shrink Structure https://bugs.webkit.org/show_bug.cgi?id=207827 Reviewed by Saam Barati. This patch shrinks sizeof(Structure) from 112 to 96 (16 bytes) in architectures using 64 bit pointers. Structure is one of the most frequently allocated JSCell in JSC. So it is worth doing all the sort of bit hacks to make it compact as much as possible. 1. Put outOfLineTypeFlags, maxOffset and transitionOffset into highest bits of m_propertyTableUnsafe, m_cachedPrototypeChain, m_classInfo, and m_transitionPropertyName. Do not use PackedPtr here since some of them are concurrently accessed by GC. 2. Put m_inlineCapacity into lower 8 bits of m_propertyHash. 3. Remove m_lock, and use Structure::cellLock() instead. 4. Remove m_cachedPrototypeChain clearing from the concurrent collector since it is dead code, it was old code. We were setting m_cachedPrototypeChain only if Structure is for JSObject. Clearing happened only if it was not a Structure for JSObject. 5. Previous Structure is held as StructureID m_previous. And m_previousOrRareData becomes m_cachedPrototypeChainOrRareData. Many pairs are using CompactPointerTuple to make code clean. Combining all of the above techniques saves us 16 bytes. * bytecode/AccessCase.cpp: (JSC::AccessCase::create): (JSC::AccessCase::propagateTransitions const): * bytecode/AccessCase.h: (JSC::AccessCase::structure const): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileObjectKeys): (JSC::DFG::SpeculativeJIT::compileCreateThis): (JSC::DFG::SpeculativeJIT::compileCreatePromise): (JSC::DFG::SpeculativeJIT::compileCreateInternalFieldObject): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys): (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitLoadClassInfoFromStructure): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_create_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_create_this): * jit/Repatch.cpp: (JSC::tryCachePutByID): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createStructure): * runtime/ConcurrentJSLock.h: (JSC::ConcurrentJSLockerBase::ConcurrentJSLockerBase): (JSC::GCSafeConcurrentJSLockerImpl::GCSafeConcurrentJSLockerImpl): (JSC::GCSafeConcurrentJSLockerImpl::~GCSafeConcurrentJSLockerImpl): (JSC::ConcurrentJSLockerImpl::ConcurrentJSLockerImpl): (JSC::GCSafeConcurrentJSLocker::GCSafeConcurrentJSLocker): Deleted. (JSC::GCSafeConcurrentJSLocker::~GCSafeConcurrentJSLocker): Deleted. (JSC::ConcurrentJSLocker::ConcurrentJSLocker): Deleted. * runtime/JSCell.h: * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): (JSC::JSObject::shiftButterflyAfterFlattening): * runtime/JSObject.h: (JSC::JSObject::getDirectConcurrently const): * runtime/JSObjectInlines.h: (JSC::JSObject::prepareToPutDirectWithoutTransition): * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains const): (JSC::StructureTransitionTable::get const): (JSC::StructureTransitionTable::add): (JSC::Structure::dumpStatistics): (JSC::Structure::Structure): (JSC::Structure::create): (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::materializePropertyTable): (JSC::Structure::addPropertyTransitionToExistingStructureImpl): (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): (JSC::Structure::addNewPropertyTransition): (JSC::Structure::removeNewPropertyTransition): (JSC::Structure::changePrototypeTransition): (JSC::Structure::attributeChangeTransition): (JSC::Structure::toDictionaryTransition): (JSC::Structure::takePropertyTableOrCloneIfPinned): (JSC::Structure::nonPropertyTransitionSlow): (JSC::Structure::flattenDictionaryStructure): (JSC::Structure::pin): (JSC::Structure::pinForCaching): (JSC::Structure::allocateRareData): (JSC::Structure::ensurePropertyReplacementWatchpointSet): (JSC::Structure::copyPropertyTableForPinning): (JSC::Structure::add): (JSC::Structure::remove): (JSC::Structure::visitChildren): (JSC::Structure::canCachePropertyNameEnumerator const): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::get): (JSC::Structure::ruleOutUnseenProperty const): (JSC::Structure::seenProperties const): (JSC::Structure::addPropertyHashAndSeenProperty): (JSC::Structure::forEachPropertyConcurrently): (JSC::Structure::transitivelyTransitionedFrom): (JSC::Structure::cachedPrototypeChain const): (JSC::Structure::setCachedPrototypeChain): (JSC::Structure::prototypeChain const): (JSC::Structure::propertyReplacementWatchpointSet): (JSC::Structure::checkOffsetConsistency const): (JSC::Structure::add): (JSC::Structure::remove): (JSC::Structure::removePropertyWithoutTransition): (JSC::Structure::setPropertyTable): (JSC::Structure::clearPropertyTable): (JSC::Structure::setOutOfLineTypeFlags): (JSC::Structure::setInlineCapacity): (JSC::Structure::setClassInfo): (JSC::Structure::setPreviousID): (JSC::Structure::clearPreviousID): * runtime/StructureRareData.cpp: (JSC::StructureRareData::createStructure): (JSC::StructureRareData::create): (JSC::StructureRareData::StructureRareData): (JSC::StructureRareData::visitChildren): * runtime/StructureRareData.h: * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setCachedPrototypeChain): (JSC::StructureRareData::setPreviousID): Deleted. (JSC::StructureRareData::clearPreviousID): Deleted. * tools/JSDollarVM.cpp: (JSC::JSDollarVMHelper::functionGetStructureTransitionList): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): 2020-02-20 Mark Lam Make support for bytecode caching more robust against file corruption. https://bugs.webkit.org/show_bug.cgi?id=207972 Reviewed by Yusuke Suzuki. If a bytecode cache file is corrupted, we currently will always crash every time we try to read it (in perpetuity as long as the corrupted cache file continues to exist on disk). To guard against this, we'll harden the bytecode caching mechanism as follows: 1. Modify the writeCache operation to always write the cache file in a transactional manner i.e. we'll first write to a .tmp file, and then rename the .tmp file to the cache file only if the entire file has been written in completeness. This ensures that we won't get corrupted cache files due to interrupted writes. 2. Modify the writeCache operation to also compute a SHA1 hash of the cache file and append the hash at end of the file. Modify the readCache operation to first authenticate the SHA1 hash before allowing the cache file to be used. If the hash does not match, the file is bad, and we'll just delete it. This ensures that we won't be crashing while decoding a corrupted cache file. Manually tested with the following scenarios and ensuring that the client recovers with no crashes: 1. no cache file on disk. 2. a 0-sized cache file on a disk. 3. a truncated cache file on disk. 4. a corrupted cache file on disk. 5. an uncorrupted cache file on disk. Also added some static_asserts in CachedTypes.cpp to document some invariants that the pre-existing code is dependent on. * API/JSScript.mm: (-[JSScript readCache]): (-[JSScript writeCache:]): * runtime/CachedTypes.cpp: 2020-02-19 Ross Kirsling Computed Properties with increment sometimes produces incorrect results https://bugs.webkit.org/show_bug.cgi?id=170934 Reviewed by Yusuke Suzuki. When the key and value of a computed property each have side effects, the eval order should be key-before-value. Not only have we had this backwards, we've also been giving them both the same target register. * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitPutConstantProperty): 2020-02-19 Keith Miller Disable Wasm reference types by default https://bugs.webkit.org/show_bug.cgi?id=207952 Reviewed by Mark Lam. * runtime/OptionsList.h: 2020-02-19 Stephan Szabo [PlayStation] Get jsc test wrappers using find_package https://bugs.webkit.org/show_bug.cgi?id=207914 Reviewed by Ross Kirsling. * shell/PlatformPlayStation.cmake: 2020-02-18 Keith Miller Add an os_log PrintStream https://bugs.webkit.org/show_bug.cgi?id=207898 Reviewed by Mark Lam. Add jsc option to write dataLogs to os_log. * runtime/Options.cpp: (JSC::Options::initialize): * runtime/OptionsList.h: 2020-02-18 Paulo Matos Fix order (in MIPS) under which CS-registers are saved/restored https://bugs.webkit.org/show_bug.cgi?id=207752 Reviewed by Keith Miller. This has been causing several segfaults on MIPS with JIT enabled because during an OSR to baseline, the order in which LLInt was saving the registers was not in sync with the way baseline was restoring them. * llint/LowLevelInterpreter.asm: 2020-02-18 Ross Kirsling [JSC] Computed function properties compute their keys twice https://bugs.webkit.org/show_bug.cgi?id=207297 Reviewed by Keith Miller. If a pseudo-String is used as the key of a computed function property, any side effects from resolving the string value occur in duplicate. The cause has two parts: - We aren't ensuring that the string value is resolved before doing SetFunctionName and PutByVal. - Our implementation of SetFunctionName (https://tc39.es/ecma262/#sec-setfunctionname) calls toString on a non-symbol argument, instead of assuming the type is a string. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::shouldSetFunctionName): Added. (JSC::BytecodeGenerator::emitSetFunctionName): Added. (JSC::BytecodeGenerator::emitSetFunctionNameIfNeededImpl): Deleted. (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded): Deleted. * bytecompiler/BytecodeGenerator.h: Split the "if needed" logic out into its own function. * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): (JSC::PropertyListNode::emitPutConstantProperty): (JSC::DefineFieldNode::emitBytecode): Never emit OpSetFunctionName for a name of unknown type. (But also, don't perform a needless ToPropertyKey for non-function computed property keys.) * runtime/JSFunction.cpp: (JSC::JSFunction::setFunctionName): Don't call toString, assert isString. 2020-02-17 Yusuke Suzuki [JSC] JITThunk should be HashSet> with appropriate GC weakness handling https://bugs.webkit.org/show_bug.cgi?id=207715 Reviewed by Darin Adler. This patch refines JITThunks GC-aware Weak hash map for NativeExecutable. Previously, we have HashMap, Weak> table. But this is not good because the first tuple's information is already in NativeExecutable. But we were using this design since Weak can be nullified because of Weak<>. If this happens, we could have invalid Entry in HashMap which does not have corresponding values. This will cause crash when rehasing requires hash code for this entry. But this HashMap is very bad in terms of memory usage. Each entry has 32 bytes, and this table gets enough large. We identified that this table is consuming much memory in Membuster. So it is worth designing carefully crafted data structure which only holds Weak by leveraging the deep interaction with our GC implementation. This patch implements new design of JITThunks, which uses HashSet> and carefully crafted HashTraits / KeyTraits to handle Weak<> well. 1. Each Weak should have finalizer, and this finalizer should remove dead Weak from HashSet. This is ensuring that all the keys in HashSet is, even if Weak<> is saying it is Dead, it still has an way to access content of NativeExecutable if the content is not a JS objects. For example, we can get function pointer from dead Weak if it is not yet finalized. Since we remove all finalized Weak<> from the table, this finalizer mechanism allows us to access function pointers etc. from Weak so long as it is held in this table. 2. Getting NativeExecutable* from JITThunks should have special protocol. When getting NativeExecutable* from JITThunks, we do the following, 1. First, we check we have an Entry in JITThunks. If it does not exist, we should insert it anyway. 1.1. If it exists, we should check whether this Weak is dead or not. It is possible that dead one is still in the table because "dead" does not mean that it is "finalized". Until finalizing happens (and it can be delayed by incremental-sweeper), Weak can be dead but still accessible. So the table is still holding dead one. If we get dead one, we should insert a new one. 1.2. If it is not dead, we return it. 2. Second, we create a new NativeExecutable and insert it. In that case, it is possible that the table already has Weak, but it is dead. In that case, we need to explicitly replace it with newly created one since old one is holding old content. If we replaced, finalizer of Weak<> will not be invoked since it immediately deallocates Weak<>. So, it does not happen that this newly inserted NativeExecutable* is removed by the finalizer registered by the old Weak<>. This change makes memory usage of JITThunks table 1/4. * heap/Weak.cpp: (JSC::weakClearSlowCase): * heap/Weak.h: (JSC::Weak::Weak): (JSC::Weak::isHashTableEmptyValue const): (JSC::Weak::unsafeImpl const): (WTF::HashTraits>::isEmptyValue): * heap/WeakInlines.h: (JSC::Weak::Weak): * jit/JITThunks.cpp: (JSC::JITThunks::JITThunks): (JSC::JITThunks::WeakNativeExecutableHash::hash): (JSC::JITThunks::WeakNativeExecutableHash::equal): (JSC::JITThunks::HostKeySearcher::hash): (JSC::JITThunks::HostKeySearcher::equal): (JSC::JITThunks::NativeExecutableTranslator::hash): (JSC::JITThunks::NativeExecutableTranslator::equal): (JSC::JITThunks::NativeExecutableTranslator::translate): (JSC::JITThunks::finalize): (JSC::JITThunks::hostFunctionStub): (JSC::JITThunks::clearHostFunctionStubs): Deleted. * jit/JITThunks.h: * runtime/NativeExecutable.h: * tools/JSDollarVM.cpp: (JSC::functionGCSweepAsynchronously): (JSC::functionCreateEmptyFunctionWithName): (JSC::JSDollarVM::finishCreation): 2020-02-17 Tadeu Zagallo [Wasm] REGRESSION(r256665): Wasm->JS call IC needs to save memory size register https://bugs.webkit.org/show_bug.cgi?id=207849 Reviewed by Mark Lam. When generating the call IC, we should select the callee saves using BoundsChecking mode in order to obey to the calling conventions described in r256665. Currently, we won't restore the memory size register when calling the Wasm LLInt through the call IC. * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::calleeSaves const): 2020-02-17 Per Arne Vollan Mach lookup to com.apple.webinspector should not be allowed in WebKit's WebContent process https://bugs.webkit.org/show_bug.cgi?id=203214 Reviewed by Brent Fulgham. Add static flag in RemoteInspector to indicate whether a sandbox extension is needed. The remote inspector will only be started if the sandbox extension is not needed. Only the WebContent process will need a sandbox extension, since this patch removes mach access to 'com.apple.webinspector' for this process. Also add name and domain for the 'Enable Remote Inspector' setting, since this will be used in the UI process. * inspector/remote/RemoteInspector.cpp: * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspectorConstants.h: * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::singleton): 2020-02-16 Fujii Hironori Remove remaining WTF_EXPORT and WTF_IMPORT by replacing them with WTF_EXPORT_DECLARATION and WTF_IMPORT_DECLARATION https://bugs.webkit.org/show_bug.cgi?id=207746 Reviewed by Don Olmstead. * runtime/JSExportMacros.h: 2020-02-16 Paulo Matos Remove nonArgGPR1 for ARMv7 and ARM64 (unused) https://bugs.webkit.org/show_bug.cgi?id=207753 Reviewed by Darin Adler. Cleanup commit - nonArgGPR1 is unused for both ARMv7 and ARM64. * jit/GPRInfo.h: 2020-02-14 Tadeu Zagallo and Michael Saboff [WASM] Wasm interpreter's calling convention doesn't match Wasm JIT's convention. https://bugs.webkit.org/show_bug.cgi?id=207727 Reviewed by Mark Lam. The Wasm JIT has unusual calling conventions, which were further complicated by the addition of the interpreter, and the interpreter did not correctly follow these conventions (by incorrectly saving and restoring the callee save registers used for the memory base and size). Here's a summary of the calling convention: - When entering Wasm from JS, the wrapper must: - Preserve the base and size when entering LLInt regardless of the mode. (Prior to this patch we only preserved the base in Signaling mode) - Preserve the memory base in either mode, and the size for BoundsChecking. - Both tiers must preserve every *other* register they use. e.g. the LLInt must preserve PB and wasmInstance, but must *not* preserve memoryBase and memorySize. - Changes to memoryBase and memorySize are visible to the caller. This means that: - Intra-module calls can assume these registers are up-to-date even if the memory was resized. The only exception here is if the LLInt calls a signaling JIT, in which case the JIT will not update the size register, since it won't be using it. - Inter-module and JS calls require the caller to reload these registers. These calls may result in memory changes (e.g. the callee may call memory.grow). - A Signaling JIT caller must be aware that the LLInt may trash the size register, since it always bounds checks. * llint/WebAssembly.asm: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::addCall): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addCall): * wasm/WasmCallee.cpp: (JSC::Wasm::LLIntCallee::calleeSaveRegisters): * wasm/WasmCallingConvention.h: * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::didCompleteCompilation): * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::PinnedRegisterInfo::get): (JSC::Wasm::getPinnedRegisters): Deleted. 2020-02-13 Stephan Szabo [PlayStation] Make special udis86 C file handling only happen for Visual Studio https://bugs.webkit.org/show_bug.cgi?id=207729 Reviewed by Don Olmstead. * PlatformPlayStation.cmake: 2020-02-13 Caio Lima [ESNext][BigInt] We don't support BigInt literal as PropertyName https://bugs.webkit.org/show_bug.cgi?id=206888 Reviewed by Ross Kirsling. According to spec (https://tc39.es/ecma262/#prod-PropertyName), BigInt literals are valid property names. Given that, we should not throw a SyntaxError when using BigInt literals on destructuring pattern, method declaration, object literals, etc. This patch is adding BigInt literal as a valid syntax to PropertyName. * parser/Parser.cpp: (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseClass): (JSC::Parser::parseInstanceFieldInitializerSourceElements): (JSC::Parser::parseProperty): (JSC::Parser::parseGetterSetter): * parser/ParserArena.cpp: (JSC::IdentifierArena::makeBigIntDecimalIdentifier): * parser/ParserArena.h: 2020-02-12 Mark Lam Add options for debugging WASM code. https://bugs.webkit.org/show_bug.cgi?id=207677 Reviewed by Yusuke Suzuki. Specifically ... JSC_useBBQJIT - allows the BBQ JIT to be used if true JSC_useOMGJIT - allows the OMG JIT to be used if true JSC_useWasmLLIntPrologueOSR - allows prologue OSR from Wasm LLInt if true JSC_useWasmLLIntLoopOSR - allows loop OSR from Wasm LLInt if true JSC_useWasmLLIntEpilogueOSR - allows epilogue OSR from Wasm LLInt if true JSC_wasmFunctionIndexRangeToCompile=N:M - wasm function index range to allow compilation on, e.g. 1:100 * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/Options.cpp: (JSC::Options::ensureOptionsAreCoherent): * runtime/OptionsList.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::OMGForOSREntryPlan): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): * wasm/WasmOperations.cpp: (JSC::Wasm::shouldJIT): (JSC::Wasm::operationWasmTriggerOSREntryNow): (JSC::Wasm::operationWasmTriggerTierUpNow): * wasm/WasmSlowPaths.cpp: (JSC::LLInt::shouldJIT): (JSC::LLInt::WASM_SLOW_PATH_DECL): 2020-02-12 Yusuke Suzuki [JSC] Compact JITCodeMap by storing BytecodeIndex and CodeLocation separately https://bugs.webkit.org/show_bug.cgi?id=207673 Reviewed by Mark Lam. While BytecodeIndex is 4 bytes, CodeLocation is 8 bytes. So the tuple of them "JITCodeMap::Entry" becomes 16 bytes because it adds 4 bytes padding. We should store BytecodeIndex and CodeLocation separately to avoid this padding. This patch introduces JITCodeMapBuilder. We use this to build JITCodeMap data structure as a immutable final result. * jit/JIT.cpp: (JSC::JIT::link): * jit/JITCodeMap.h: (JSC::JITCodeMap::JITCodeMap): (JSC::JITCodeMap::find const): (JSC::JITCodeMap::operator bool const): (JSC::JITCodeMap::codeLocations const): (JSC::JITCodeMap::indexes const): (JSC::JITCodeMapBuilder::append): (JSC::JITCodeMapBuilder::finalize): (JSC::JITCodeMap::Entry::Entry): Deleted. (JSC::JITCodeMap::Entry::bytecodeIndex const): Deleted. (JSC::JITCodeMap::Entry::codeLocation): Deleted. (JSC::JITCodeMap::append): Deleted. (JSC::JITCodeMap::finish): Deleted. 2020-02-12 Pavel Feldman Web Inspector: encode binary web socket frames using base64 https://bugs.webkit.org/show_bug.cgi?id=207448 Previous representation of binary frames is lossy using fromUTF8WithLatin1Fallback, this patch consistently encodes binary data using base64. Reviewed by Timothy Hatcher. * inspector/protocol/Network.json: 2020-02-12 Simon Fraser Remove CSS_DEVICE_ADAPTATION https://bugs.webkit.org/show_bug.cgi?id=203479 Reviewed by Tim Horton. CSS Working Group resolved to remove @viewport , so remove the code. * Configurations/FeatureDefines.xcconfig: 2020-02-12 Yusuke Suzuki [JSC] Compact StructureTransitionTable https://bugs.webkit.org/show_bug.cgi?id=207616 Reviewed by Mark Lam. Some of StructureTransitionTable are shown as very large HashMap and we can compact it by encoding key. We leverage 48bit pointers and 8byte alignment of UniquedStringImpl* to encode other parameters into it. * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains const): (JSC::StructureTransitionTable::get const): (JSC::StructureTransitionTable::add): * runtime/Structure.h: * runtime/StructureTransitionTable.h: (JSC::StructureTransitionTable::Hash::Key::Key): (JSC::StructureTransitionTable::Hash::Key::isHashTableDeletedValue const): (JSC::StructureTransitionTable::Hash::Key::impl const): (JSC::StructureTransitionTable::Hash::Key::isAddition const): (JSC::StructureTransitionTable::Hash::Key::attributes const): (JSC::StructureTransitionTable::Hash::Key::operator==): (JSC::StructureTransitionTable::Hash::Key::operator!=): (JSC::StructureTransitionTable::Hash::hash): (JSC::StructureTransitionTable::Hash::equal): 2020-02-12 Yusuke Suzuki [JSC] Make RegExpCache small https://bugs.webkit.org/show_bug.cgi?id=207619 Reviewed by Mark Lam. We can compact RegExpKey by using PackedRefPtr, so that we can shrink memory consumption of RegExpCache. * runtime/RegExpKey.h: 2020-02-10 Mark Lam Placate exception check validator in GenericArguments::put(). https://bugs.webkit.org/show_bug.cgi?id=207485 Reviewed by Robin Morisset. * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::put): 2020-02-10 Mark Lam Missing exception check in GenericArguments::deletePropertyByIndex(). https://bugs.webkit.org/show_bug.cgi?id=207483 Reviewed by Yusuke Suzuki. * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::deletePropertyByIndex): 2020-02-10 Truitt Savell Unreviewed, rolling out r256091. Broke internal builds Reverted changeset: "Move trivial definitions from FeatureDefines.xcconfig to PlatformEnableCocoa.h" https://bugs.webkit.org/show_bug.cgi?id=207155 https://trac.webkit.org/changeset/256091 2020-02-10 Truitt Savell Unreviewed, rolling out r256103. This patch is blocking the rollout of r256091 Reverted changeset: "Move JavaScriptCore related feature defines from FeatureDefines.xcconfig to PlatformEnableCocoa.h" https://bugs.webkit.org/show_bug.cgi?id=207436 https://trac.webkit.org/changeset/256103 2020-02-09 Keith Rollin Re-enable LTO for ARM builds https://bugs.webkit.org/show_bug.cgi?id=207402 Reviewed by Sam Weinig. Bug 190758 re-enabled LTO for Production builds for x86-family CPUs. Enabling it for ARM was left out due to a compiler issue. That issue has been fixed, and so now we can re-enable LTO for ARM. * Configurations/Base.xcconfig: 2020-02-08 Sam Weinig Move JavaScriptCore related feature defines from FeatureDefines.xcconfig to PlatformEnableCocoa.h https://bugs.webkit.org/show_bug.cgi?id=207436 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: Remove ENABLE_FAST_JIT_PERMISSIONS and ENABLE_FTL_JIT. 2020-02-08 Sam Weinig Move trivial definitions from FeatureDefines.xcconfig to PlatformEnableCocoa.h https://bugs.webkit.org/show_bug.cgi?id=207155 Reviewed by Tim Horton. Move all trivial definitions (just ENABLE_FOO = ENABLE_FOO; or ENABLE_BAR = ;) from the FeatureDefines.xcconfigs to PlatformEnableCocoa.h, ensuring each one also has a default value in PlatformEnable.h To support the move, DerivedSources.make has been updated to generate the list of ENABLE_* features by directly from preprocessing Platform.h, rather than just getting the partial list from the xcconfig file. * Configurations/FeatureDefines.xcconfig: * DerivedSources.make: 2020-02-07 Robin Morisset Throw OutOfMemory exception instead of crashing if DirectArguments/ScopedArguments can't be created https://bugs.webkit.org/show_bug.cgi?id=207423 Reviewed by Mark Lam. AllocationFailureMode::Assert is problematic because fuzzers keep producing spurious error reports when they generate code that tries allocating infinite amount of memory. The right approach is to use AllocationFailureMode::ReturnNull, and throw a JS exception upon receiving null. In this patch I fixed two functions that were using AllocationFailureMode::Assert: DirectArguments::DirectArguments::overrideThings GenericArguments::initModifiedArgumentsDescriptor No test added, because the only test we have is highly non-deterministic/flaky (only triggers about 10 to 20% of the time even before the fix). * runtime/DirectArguments.h: * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::deletePropertyByIndex): (JSC::GenericArguments::defineOwnProperty): (JSC::GenericArguments::initModifiedArgumentsDescriptor): (JSC::GenericArguments::initModifiedArgumentsDescriptorIfNecessary): (JSC::GenericArguments::setModifiedArgumentDescriptor): * runtime/ScopedArguments.h: 2020-02-07 Ryan Haddad Unreviewed, rolling out r256051. Broke internal builds. Reverted changeset: "Move trivial definitions from FeatureDefines.xcconfig to PlatformEnableCocoa.h" https://bugs.webkit.org/show_bug.cgi?id=207155 https://trac.webkit.org/changeset/256051 2020-02-07 Sam Weinig Move trivial definitions from FeatureDefines.xcconfig to PlatformEnableCocoa.h https://bugs.webkit.org/show_bug.cgi?id=207155 Reviewed by Tim Horton. Move all trivial definitions (just ENABLE_FOO = ENABLE_FOO; or ENABLE_BAR = ;) from the FeatureDefines.xcconfigs to PlatformEnableCocoa.h, ensuring each one also has a default value in PlatformEnable.h To support the move, DerivedSources.make has been updated to generate the list of ENABLE_* features by directly from preprocessing Platform.h, rather than just getting the partial list from the xcconfig file. * Configurations/FeatureDefines.xcconfig: * DerivedSources.make: 2020-02-07 Yusuke Suzuki [JSC] CodeBlock::shrinkToFit should shrink m_constantRegisters and m_constantsSourceCodeRepresentation in 64bit architectures https://bugs.webkit.org/show_bug.cgi?id=207356 Reviewed by Mark Lam. Only 32bit architectures are using m_constantRegisters's address. 64bit architectures are not relying on m_constantRegisters's address. This patches fixes the thing so that CodeBlock::shrinkToFit will shrink m_constantRegisters and m_constantsSourceCodeRepresentation regardless of whether this is EarlyShrink or not. We also move DFG/FTL's LateShrink call to the place after calling DFGCommon reallyAdd since they can add more constant registers. Relanding it by fixing dead-lock. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shrinkToFit): * bytecode/CodeBlock.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalizeCommon): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * jit/JIT.cpp: (JSC::JIT::link): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitLoadDouble): (JSC::JIT::emitLoadInt32ToDouble): Deleted. 2020-02-06 Robin Morisset Most of B3 and Air does not need to include CCallHelpers.h https://bugs.webkit.org/show_bug.cgi?id=206975 Reviewed by Mark Lam. They only do to use CCallHelpers::Jump or CCallHelpers::Label. But CCallHelpers inherit those from MacroAssembler. And MacroAssembler.h is dramatically cheaper to include (since CCallHelpers includes AssemblyHelpers which includes CodeBlock.h which includes roughly the entire runtime). * b3/B3CheckSpecial.cpp: * b3/B3CheckSpecial.h: * b3/B3LowerMacros.cpp: * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::generate): * b3/B3PatchpointSpecial.h: * b3/B3StackmapGenerationParams.cpp: (JSC::B3::StackmapGenerationParams::successorLabels const): * b3/B3StackmapGenerationParams.h: * b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: * b3/air/AirCCallSpecial.cpp: * b3/air/AirCCallSpecial.h: * b3/air/AirCode.cpp: * b3/air/AirCode.h: (JSC::B3::Air::Code::entrypointLabel const): * b3/air/AirCustom.cpp: (JSC::B3::Air::CCallCustom::generate): (JSC::B3::Air::ShuffleCustom::generate): (JSC::B3::Air::WasmBoundsCheckCustom::generate): * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::generate): (JSC::B3::Air::EntrySwitchCustom::generate): * b3/air/AirDisassembler.cpp: (JSC::B3::Air::Disassembler::addInst): * b3/air/AirDisassembler.h: * b3/air/AirGenerationContext.h: * b3/air/AirInst.h: * b3/air/AirPrintSpecial.cpp: (JSC::B3::Air::PrintSpecial::generate): * b3/air/AirPrintSpecial.h: * b3/air/AirSpecial.h: * b3/air/AirValidate.cpp: * b3/air/opcode_generator.rb: 2020-02-06 Commit Queue Unreviewed, rolling out r255987. https://bugs.webkit.org/show_bug.cgi?id=207369 JSTests failures (Requested by yusukesuzuki on #webkit). Reverted changeset: "[JSC] CodeBlock::shrinkToFit should shrink m_constantRegisters and m_constantsSourceCodeRepresentation in 64bit architectures" https://bugs.webkit.org/show_bug.cgi?id=207356 https://trac.webkit.org/changeset/255987 2020-02-06 Yusuke Suzuki [JSC] CodeBlock::shrinkToFit should shrink m_constantRegisters and m_constantsSourceCodeRepresentation in 64bit architectures https://bugs.webkit.org/show_bug.cgi?id=207356 Reviewed by Mark Lam. Only 32bit architectures are using m_constantRegisters's address. 64bit architectures are not relying on m_constantRegisters's address. This patches fixes the thing so that CodeBlock::shrinkToFit will shrink m_constantRegisters and m_constantsSourceCodeRepresentation regardless of whether this is EarlyShrink or not. We also move DFG/FTL's LateShrink call to the place after calling DFGCommon reallyAdd since they can add more constant registers. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shrinkToFit): * bytecode/CodeBlock.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalizeCommon): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * jit/JIT.cpp: (JSC::JIT::link): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitLoadDouble): (JSC::JIT::emitLoadInt32ToDouble): Deleted. 2020-02-05 Don Olmstead [PlayStation] Build a shared JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=198446 Reviewed by Fujii Hironori. Add TARGET_OBJECTS for bmalloc and WTF so JavaScriptCore links. Add bmalloc and WTF compile definitions so exports are exposed. * PlatformPlayStation.cmake: 2020-02-05 Justin Michaud Deleting a property should not turn structures into uncacheable dictionaries https://bugs.webkit.org/show_bug.cgi?id=206430 Reviewed by Yusuke Suzuki. Right now, deleteProperty/removePropertyTransition causes a structure transition to uncacheable dictionary. Instead, we should allow it to transition to a new regular structure like adding a property does. This means that we have to: 1) Break the assumption that structure transition offsets increase monotonically We add a new flag to tell that a structure has deleted its property, and update materializePropertyTable to use it. 2) Add a new transition map and transition kind for deletes We cache the delete transition. We will not transition back to a previous structure if you add then immediately remove a property. 3) Find some heuristic for when we should actually transition to uncacheable dictionary. Since deleting properties is expected to be rare, we just walk the structure list and count its size on removal. This patch also fixes a related bug in addProperty, where we did not use a GCSafeConcurrentJSLocker, and adds an option to trigger the bug. Finally, we add some helper methods to dollarVM to test. This gives a 24x speedup on delete-property-keeps-cacheable-structure.js, and is neutral on delete-property-from-prototype-chain.js (which was already generating code using the inline cache). * heap/HeapInlines.h: (JSC::Heap::decrementDeferralDepthAndGCIfNeeded): * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): * runtime/OptionsList.h: * runtime/PropertyMapHashTable.h: (JSC::PropertyTable::get): (JSC::PropertyTable::add): (JSC::PropertyTable::addDeletedOffset): (JSC::PropertyTable::reinsert): * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains const): (JSC::StructureTransitionTable::get const): (JSC::StructureTransitionTable::add): (JSC::Structure::Structure): (JSC::Structure::materializePropertyTable): (JSC::Structure::addNewPropertyTransition): (JSC::Structure::removePropertyTransition): (JSC::Structure::removePropertyTransitionFromExistingStructure): (JSC::Structure::removeNewPropertyTransition): (JSC::Structure::toUncacheableDictionaryTransition): (JSC::Structure::remove): (JSC::Structure::visitChildren): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::forEachPropertyConcurrently): (JSC::Structure::add): (JSC::Structure::remove): (JSC::Structure::removePropertyWithoutTransition): * runtime/StructureTransitionTable.h: (JSC::StructureTransitionTable::Hash::hash): * tools/JSDollarVM.cpp: (JSC::JSDollarVMHelper::functionGetStructureTransitionList): (JSC::functionGetConcurrently): (JSC::JSDollarVM::finishCreation): 2020-02-05 Devin Rousso Web Inspector: Sources: add a special breakpoint for controlling whether `debugger` statements pause https://bugs.webkit.org/show_bug.cgi?id=206818 Reviewed by Timothy Hatcher. * inspector/protocol/Debugger.json: * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::setPauseOnDebuggerStatements): Added. * bytecompiler/NodesCodegen.cpp: (JSC::DebuggerStatementNode::emitBytecode): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/UnlinkedCodeBlock.cpp: (JSC::dumpLineColumnEntry): * interpreter/Interpreter.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::debug): (WTF::printInternal): * debugger/Debugger.h: (JSC::Debugger::setPauseOnDebuggerStatements): Added. * debugger/Debugger.cpp: (JSC::Debugger::didReachDebuggerStatement): Added. (JSC::Debugger::didReachBreakpoint): Deleted. Replace `DebugHookType::DidReachBreakpoint` with `DebugHookType::DidReachDebuggerStatement`, as it is only actually used for `debugger;` statements, not breakpoints. 2020-02-04 Yusuke Suzuki [JSC] Structure::setMaxOffset and setTransitionOffset are racy https://bugs.webkit.org/show_bug.cgi?id=207249 Reviewed by Mark Lam. We hit crash in JSTests/stress/array-slice-osr-exit-2.js. The situation is following. 1. The mutator thread (A) is working. 2. The concurrent collector (B) is working. 3. A attempts to set m_maxOffset in StructureRareData by allocating it. First, A sets Structure::m_maxOffset to useRareDataFlag. 3. B is in JSObject::visitButterflyImpl, and executing Structure::maxOffset(). 4. B detects that m_maxOffset is useRareDataFlag. 5. B attempts to load rareData, but this is not a StructureRareData since A is just now setting up StructureRareData. 6. B crashes. Set useRareDataFlag after StructureRareData is set. Ensuring this store-order by using storeStoreFence. * runtime/Structure.h: 2020-02-04 Adrian Perez de Castro Non-unified build fixes early February 2020 edition https://bugs.webkit.org/show_bug.cgi?id=207227 Reviewed by Don Olmstead. * bytecode/PolyProtoAccessChain.h: Add missing inclusions of StructureIDTable.h and VM.h 2020-02-04 Alex Christensen Fix Mac CMake build https://bugs.webkit.org/show_bug.cgi?id=207231 * PlatformMac.cmake: 2020-02-04 Yusuke Suzuki [JSC] Use PackedRefPtr in UnlinkedCodeBlock https://bugs.webkit.org/show_bug.cgi?id=207229 Reviewed by Mark Lam. Use PackedRefPtr in UnlinkedCodeBlock to compact it from 168 to 160, which saves 16 bytes (10%) per UnlinkedCodeBlock since we have 16 bytes alignment for GC cells. * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::sourceURLDirective const): (JSC::UnlinkedCodeBlock::sourceMappingURLDirective const): (JSC::UnlinkedCodeBlock::setSourceURLDirective): (JSC::UnlinkedCodeBlock::setSourceMappingURLDirective): * runtime/CachedTypes.cpp: (JSC::CachedCodeBlock::sourceURLDirective const): (JSC::CachedCodeBlock::sourceMappingURLDirective const): (JSC::CachedCodeBlock::encode): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): 2020-02-04 Alexey Shvayka Quantifiers after lookahead assertions should be syntax errors in Unicode patterns only https://bugs.webkit.org/show_bug.cgi?id=206988 Reviewed by Darin Adler and Ross Kirsling. This change adds SyntaxError for quantifiable assertions in Unicode patterns, aligning JSC with V8 and SpiderMonkey. Grammar: https://tc39.es/ecma262/#prod-annexB-Term (/u flag precludes the use of QuantifiableAssertion) Return value of parseParenthesesEnd() now matches with parseEscape() and parseAtomEscape(). * yarr/YarrParser.h: (JSC::Yarr::Parser::parseParenthesesBegin): (JSC::Yarr::Parser::parseParenthesesEnd): (JSC::Yarr::Parser::parseTokens): 2020-02-04 Yusuke Suzuki [JSC] Introduce UnlinkedCodeBlockGenerator and reduce sizeof(UnlinkedCodeBlock) https://bugs.webkit.org/show_bug.cgi?id=207087 Reviewed by Tadeu Zagallo. While UnlinkedCodeBlock is immutable once it is created from BytecodeGenerator, it has many mutable Vectors. This is because we are using UnlinkedCodeBlock as a builder of UnlinkedCodeBlock itself too in BytecodeGenerator. Since Vector takes 16 bytes to allow efficient expansions, it is nice if we can use RefCountedArray instead when we know this Vector is immutable. In this patch, we introduce UnlinkedCodeBlockGenerator wrapper. BytecodeGenerator, BytecodeRewriter, BytecodeDumper, and BytecodeGeneratorification interact with UnlinkedCodeBlockGenerator instead of UnlinkedCodeBlock. And UnlinkedCodeBlockGenerator will generate the finalized UnlinkedCodeBlock. This design allows us to use RefCountedArray for data in UnlinkedCodeBlock, which is (1) smaller and (2) doing shrinkToFit operation when creating it from Vector. This patch reduces sizeof(UnlinkedCodeBlock) from 256 to 168, 88 bytes reduction. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/BytecodeBasicBlock.cpp: (JSC::BytecodeBasicBlock::compute): * bytecode/BytecodeBasicBlock.h: * bytecode/BytecodeDumper.cpp: * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::BytecodeGeneratorification): (JSC::GeneratorLivenessAnalysis::run): (JSC::BytecodeGeneratorification::run): (JSC::performGeneratorification): * bytecode/BytecodeGeneratorification.h: * bytecode/BytecodeRewriter.h: (JSC::BytecodeRewriter::BytecodeRewriter): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantIdentifierSetRegisters): (JSC::CodeBlock::setConstantRegisters): (JSC::CodeBlock::handlerForIndex): (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/CodeBlock.h: (JSC::CodeBlock::numberOfSwitchJumpTables const): (JSC::CodeBlock::numberOfStringSwitchJumpTables const): (JSC::CodeBlock::addSwitchJumpTable): Deleted. (JSC::CodeBlock::addStringSwitchJumpTable): Deleted. * bytecode/HandlerInfo.h: (JSC::HandlerInfoBase::handlerForIndex): * bytecode/JumpTable.h: (JSC::SimpleJumpTable::add): Deleted. * bytecode/PreciseJumpTargets.cpp: (JSC::computePreciseJumpTargets): (JSC::recomputePreciseJumpTargets): (JSC::findJumpTargetsForInstruction): * bytecode/PreciseJumpTargets.h: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::UnlinkedCodeBlock::visitChildren): (JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeIndex const): (JSC::UnlinkedCodeBlock::handlerForIndex): (JSC::UnlinkedCodeBlock::addExpressionInfo): Deleted. (JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo): Deleted. (JSC::UnlinkedCodeBlock::setInstructions): Deleted. (JSC::UnlinkedCodeBlock::applyModification): Deleted. (JSC::UnlinkedCodeBlock::shrinkToFit): Deleted. (JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget): Deleted. * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::expressionInfo): (JSC::UnlinkedCodeBlock::setNumParameters): (JSC::UnlinkedCodeBlock::numberOfIdentifiers const): (JSC::UnlinkedCodeBlock::identifiers const): (JSC::UnlinkedCodeBlock::bitVector): (JSC::UnlinkedCodeBlock::constantRegisters): (JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): (JSC::UnlinkedCodeBlock::constantIdentifierSets): (JSC::UnlinkedCodeBlock::numberOfJumpTargets const): (JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables const): (JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables const): (JSC::UnlinkedCodeBlock::numberOfFunctionDecls): (JSC::UnlinkedCodeBlock::numberOfExceptionHandlers const): (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const): (JSC::UnlinkedCodeBlock::createRareDataIfNecessary): (JSC::UnlinkedCodeBlock::addParameter): Deleted. (JSC::UnlinkedCodeBlock::addIdentifier): Deleted. (JSC::UnlinkedCodeBlock::addBitVector): Deleted. (JSC::UnlinkedCodeBlock::addSetConstant): Deleted. (JSC::UnlinkedCodeBlock::addConstant): Deleted. (JSC::UnlinkedCodeBlock::addJumpTarget): Deleted. (JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted. (JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted. (JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted. (JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted. (JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted. (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted. (JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets): Deleted. * bytecode/UnlinkedCodeBlockGenerator.cpp: Added. (JSC::UnlinkedCodeBlockGenerator::getLineAndColumn const): (JSC::UnlinkedCodeBlockGenerator::addExpressionInfo): (JSC::UnlinkedCodeBlockGenerator::addTypeProfilerExpressionInfo): (JSC::UnlinkedCodeBlockGenerator::finalize): (JSC::UnlinkedCodeBlockGenerator::handlerForBytecodeIndex): (JSC::UnlinkedCodeBlockGenerator::handlerForIndex): (JSC::UnlinkedCodeBlockGenerator::applyModification): (JSC::UnlinkedCodeBlockGenerator::addOutOfLineJumpTarget): (JSC::UnlinkedCodeBlockGenerator::outOfLineJumpOffset): (JSC::UnlinkedCodeBlockGenerator::dump const): * bytecode/UnlinkedCodeBlockGenerator.h: Added. (JSC::UnlinkedCodeBlockGenerator::UnlinkedCodeBlockGenerator): (JSC::UnlinkedCodeBlockGenerator::vm): (JSC::UnlinkedCodeBlockGenerator::isConstructor const): (JSC::UnlinkedCodeBlockGenerator::constructorKind const): (JSC::UnlinkedCodeBlockGenerator::superBinding const): (JSC::UnlinkedCodeBlockGenerator::scriptMode const): (JSC::UnlinkedCodeBlockGenerator::needsClassFieldInitializer const): (JSC::UnlinkedCodeBlockGenerator::isStrictMode const): (JSC::UnlinkedCodeBlockGenerator::usesEval const): (JSC::UnlinkedCodeBlockGenerator::parseMode const): (JSC::UnlinkedCodeBlockGenerator::isArrowFunction): (JSC::UnlinkedCodeBlockGenerator::derivedContextType const): (JSC::UnlinkedCodeBlockGenerator::evalContextType const): (JSC::UnlinkedCodeBlockGenerator::isArrowFunctionContext const): (JSC::UnlinkedCodeBlockGenerator::isClassContext const): (JSC::UnlinkedCodeBlockGenerator::numCalleeLocals const): (JSC::UnlinkedCodeBlockGenerator::numVars const): (JSC::UnlinkedCodeBlockGenerator::numParameters const): (JSC::UnlinkedCodeBlockGenerator::thisRegister const): (JSC::UnlinkedCodeBlockGenerator::scopeRegister const): (JSC::UnlinkedCodeBlockGenerator::wasCompiledWithDebuggingOpcodes const): (JSC::UnlinkedCodeBlockGenerator::hasCheckpoints const): (JSC::UnlinkedCodeBlockGenerator::hasTailCalls const): (JSC::UnlinkedCodeBlockGenerator::setHasCheckpoints): (JSC::UnlinkedCodeBlockGenerator::setHasTailCalls): (JSC::UnlinkedCodeBlockGenerator::setNumCalleeLocals): (JSC::UnlinkedCodeBlockGenerator::setNumVars): (JSC::UnlinkedCodeBlockGenerator::setThisRegister): (JSC::UnlinkedCodeBlockGenerator::setScopeRegister): (JSC::UnlinkedCodeBlockGenerator::setNumParameters): (JSC::UnlinkedCodeBlockGenerator::metadata): (JSC::UnlinkedCodeBlockGenerator::addOpProfileControlFlowBytecodeOffset): (JSC::UnlinkedCodeBlockGenerator::numberOfJumpTargets const): (JSC::UnlinkedCodeBlockGenerator::addJumpTarget): (JSC::UnlinkedCodeBlockGenerator::jumpTarget const): (JSC::UnlinkedCodeBlockGenerator::lastJumpTarget const): (JSC::UnlinkedCodeBlockGenerator::numberOfSwitchJumpTables const): (JSC::UnlinkedCodeBlockGenerator::addSwitchJumpTable): (JSC::UnlinkedCodeBlockGenerator::switchJumpTable): (JSC::UnlinkedCodeBlockGenerator::numberOfStringSwitchJumpTables const): (JSC::UnlinkedCodeBlockGenerator::addStringSwitchJumpTable): (JSC::UnlinkedCodeBlockGenerator::stringSwitchJumpTable): (JSC::UnlinkedCodeBlockGenerator::numberOfExceptionHandlers const): (JSC::UnlinkedCodeBlockGenerator::exceptionHandler): (JSC::UnlinkedCodeBlockGenerator::addExceptionHandler): (JSC::UnlinkedCodeBlockGenerator::bitVector): (JSC::UnlinkedCodeBlockGenerator::addBitVector): (JSC::UnlinkedCodeBlockGenerator::numberOfConstantIdentifierSets const): (JSC::UnlinkedCodeBlockGenerator::constantIdentifierSets): (JSC::UnlinkedCodeBlockGenerator::addSetConstant): (JSC::UnlinkedCodeBlockGenerator::constantRegister const): (JSC::UnlinkedCodeBlockGenerator::constantRegisters): (JSC::UnlinkedCodeBlockGenerator::getConstant const): (JSC::UnlinkedCodeBlockGenerator::constantsSourceCodeRepresentation): (JSC::UnlinkedCodeBlockGenerator::addConstant): (JSC::UnlinkedCodeBlockGenerator::addFunctionDecl): (JSC::UnlinkedCodeBlockGenerator::addFunctionExpr): (JSC::UnlinkedCodeBlockGenerator::numberOfIdentifiers const): (JSC::UnlinkedCodeBlockGenerator::identifier const): (JSC::UnlinkedCodeBlockGenerator::addIdentifier): (JSC::UnlinkedCodeBlockGenerator::outOfLineJumpOffset): (JSC::UnlinkedCodeBlockGenerator::replaceOutOfLineJumpTargets): (JSC::UnlinkedCodeBlockGenerator::metadataSizeInBytes): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeNextParameter): (JSC::BytecodeGenerator::emitPushFunctionNameScope): (JSC::prepareJumpTableForSwitch): (JSC::ForInContext::finalize): (JSC::StructureForInContext::finalize): (JSC::IndexedForInContext::finalize): * bytecompiler/BytecodeGenerator.h: * bytecompiler/BytecodeGeneratorBaseInlines.h: (JSC::BytecodeGeneratorBase::newRegister): (JSC::BytecodeGeneratorBase::addVar): * runtime/CachedTypes.cpp: (JSC::CachedVector::encode): (JSC::CachedVector::decode const): * wasm/WasmFunctionCodeBlock.h: (JSC::Wasm::FunctionCodeBlock::setNumVars): (JSC::Wasm::FunctionCodeBlock::setNumCalleeLocals): 2020-02-04 Devin Rousso Web Inspector: REGRESSION(r248287): Console: function objects saved to a $n will be invoked instead of just referenced when evaluating in the Console https://bugs.webkit.org/show_bug.cgi?id=207180 Reviewed by Joseph Pecoraro. * inspector/InjectedScriptSource.js: (CommandLineAPI): Instead of deciding whether to wrap the value given for a `$n` getter based on if the value is already a function, always wrap getter values in a function so that if the value being stored in the getter is already a function, it isn't used as the callback for the getter and therefore invoked when the getter is referenced. 2020-02-03 Yusuke Suzuki [JSC] Use PackedPtr for VariableEnvironment https://bugs.webkit.org/show_bug.cgi?id=207172 Reviewed by Mark Lam. Since VariableEnvironment's KeyValue is key: pointer + value: 2 byte, using PackedPtr can make it 8 bytes, 50% reduction. * parser/VariableEnvironment.h: * runtime/CachedTypes.cpp: (JSC::CachedRefPtr::encode): (JSC::CachedRefPtr::decode const): CachedTypes should handle PackedPtr too since VariableEnvironment starts using it. 2020-02-03 Alexey Shvayka \0 identity escapes should be syntax errors in Unicode patterns only https://bugs.webkit.org/show_bug.cgi?id=207114 Reviewed by Darin Adler. This change adds a separate check for null character because `strchr` always returns a non-null pointer when called with '\0' as second argument. Grammar: https://tc39.es/ecma262/#prod-annexB-IdentityEscape (/u flag precludes the use of SourceCharacterIdentityEscape) * yarr/YarrParser.h: (JSC::Yarr::Parser::isIdentityEscapeAnError): 2020-02-01 Alexey Shvayka Non-alphabetical \c escapes should be syntax errors in Unicode patterns only https://bugs.webkit.org/show_bug.cgi?id=207091 Reviewed by Darin Adler. This change adds SyntaxError for non-alphabetical and identity \c escapes in Unicode patterns, aligning JSC with V8 and SpiderMonkey. Grammar: https://tc39.es/ecma262/#prod-annexB-ClassEscape (/u flag precludes the use of ClassControlLetter) * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): 2020-01-31 Yusuke Suzuki [JSC] Hold StructureID instead of Structure* in PolyProtoAccessChain and DFG::CommonData https://bugs.webkit.org/show_bug.cgi?id=207086 Reviewed by Mark Lam. PolyProtoAccessChain and DFG::CommonData are kept alive so long as associated AccessCase / DFG/FTL CodeBlock is alive. They hold Vector / Vector>, but access frequency is low. And We should hold Vector instead to cut 50% of the size. * bytecode/AccessCase.cpp: (JSC::AccessCase::commit): (JSC::AccessCase::forEachDependentCell const): (JSC::AccessCase::doesCalls const): (JSC::AccessCase::visitWeak const): (JSC::AccessCase::propagateTransitions const): (JSC::AccessCase::generateWithGuard): * bytecode/AccessCase.h: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::determineLiveness): (JSC::CodeBlock::stronglyVisitWeakReferences): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InByIdStatus.cpp: (JSC::InByIdStatus::computeFor): (JSC::InByIdStatus::computeForStubInfo): (JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InByIdStatus.h: * bytecode/InstanceOfStatus.cpp: (JSC::InstanceOfStatus::computeFor): (JSC::InstanceOfStatus::computeForStubInfo): * bytecode/InstanceOfStatus.h: * bytecode/PolyProtoAccessChain.cpp: (JSC::PolyProtoAccessChain::create): (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const): (JSC::PolyProtoAccessChain::dump const): * bytecode/PolyProtoAccessChain.h: (JSC::PolyProtoAccessChain::chain const): (JSC::PolyProtoAccessChain::forEach const): (JSC::PolyProtoAccessChain::slotBaseStructure const): (JSC::PolyProtoAccessChain:: const): Deleted. * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeForStubInfo): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::summary const): (JSC::StructureStubInfo::summary): * bytecode/StructureStubInfo.h: * dfg/DFGCommonData.h: * dfg/DFGDesiredWeakReferences.cpp: (JSC::DFG::DesiredWeakReferences::reallyAdd): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * jit/Repatch.cpp: (JSC::tryCacheGetBy): (JSC::tryCachePutByID): (JSC::tryCacheInByID): 2020-01-31 Yusuke Suzuki [JSC] ShrinkToFit some vectors kept by JIT data structures https://bugs.webkit.org/show_bug.cgi?id=207085 Reviewed by Mark Lam. 1. We are allocating RareCaseProfile by using SegmentedVector since JIT code is directly accessing to RareCaseProfile*. But when creating RareCaseProfile, we can know how many RareCaseProfiles should we create: RareCaseProfile is created per slow paths of Baseline JIT bytecode. Since we already scan bytecode for the main paths, we can count it and use this number when creating RareCaseProfile. 2. Vectors held by PolymorphicAccess and PolymorphicCallStubRoutine should be kept small by calling shrinkToFit. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::setRareCaseProfiles): (JSC::CodeBlock::shrinkToFit): (JSC::CodeBlock::addRareCaseProfile): Deleted. * bytecode/CodeBlock.h: * bytecode/PolyProtoAccessChain.cpp: (JSC::PolyProtoAccessChain::create): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/ValueProfile.h: (JSC::RareCaseProfile::RareCaseProfile): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/PolymorphicCallStubRoutine.cpp: (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine): 2020-01-31 Yusuke Suzuki [JSC] DFG::CommonData::shrinkToFit called before DFG::Plan::reallyAdd is called https://bugs.webkit.org/show_bug.cgi?id=207083 Reviewed by Mark Lam. We are calling DFG::CommonData::shrinkToFit, but calling this too early: we execute DFG::Plan::reallyAdd(DFG::CommonData*) after that, and this adds many entries to DFG::CommonData*. We should call DFG::CommonData::shrinkToFit after calling DFG::Plan::reallyAdd. To implement it, we make DFG::JITCode::shrinkToFit virtual function in JSC::JITCode. Then, we can also implement FTL::JITCode::shrinkToFit which was previously not implemented. * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::shrinkToFit): * dfg/DFGJITCode.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::shrinkToFit): * ftl/FTLJITCode.h: * jit/JITCode.cpp: (JSC::JITCode::shrinkToFit): * jit/JITCode.h: 2020-01-31 Saam Barati GetButterfly should check if the input value is an object in safe to execute https://bugs.webkit.org/show_bug.cgi?id=207082 Reviewed by Mark Lam. We can only hoist GetButterfly when we know the incoming value is an object. We might want to reconsider making GetButterfly use ObjectUse as its edge kind, but that's out of the scope of this patch. Currently, we use CellUse for GetButterfly node's child1. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): 2020-01-31 Saam Barati safe to execute should return false when we know code won't be moved https://bugs.webkit.org/show_bug.cgi?id=207074 Reviewed by Yusuke Suzuki. We use safeToExecute to determine inside LICM whether it's safe to execute a node somewhere else in the program. We were returning true for nodes we knew would never be moved, because they were effectful. Things like Call and GetById. This patch makes those nodes return false now, since we want to make it easier to audit the nodes that return true. This makes that audit easier, since it gets rid of the obvious things that will never be hoisted. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): 2020-01-31 Saam Barati GetGetterSetterByOffset and GetGetter/GetSetter are not always safe to execute https://bugs.webkit.org/show_bug.cgi?id=206805 Reviewed by Yusuke Suzuki. This patch fixes two bugs. The first is GetGetterSetterByOffset. Previously, we were just checking that we could load the value safely. However, because GetGetterSetterByOffset returns a GetterSetter object, we can only safely move this node into a context where it's guaranteed that the offset loaded will return a GetterSetter. The second fix is GetGetter/GetSetter were both always marked as safe to execute. However, they're only safe to execute when the incoming value to load from is a GetterSetter object. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): 2020-01-31 Alexey Shvayka Unmatched ] or } brackets should be syntax errors in Unicode patterns only https://bugs.webkit.org/show_bug.cgi?id=207023 Reviewed by Darin Adler. This change adds SyntaxError for Unicode patterns, aligning JSC with V8 and SpiderMonkey. Grammar: https://tc39.es/ecma262/#prod-annexB-Term (/u flag precludes the use of ExtendedAtom and thus ExtendedPatternCharacter) * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::parseTokens): 2020-01-31 Don Olmstead [CMake] Add _PRIVATE_LIBRARIES to framework https://bugs.webkit.org/show_bug.cgi?id=207004 Reviewed by Konstantin Tokarev. Move uses of PRIVATE within _LIBRARIES to _PRIVATE_LIBRARIES. Any _LIBRARIES appended afterwards will have that visibility set erroneously. * PlatformFTW.cmake: 2020-01-30 Mark Lam Some improvements to DFG and FTL dumps to improve readability and searchability. https://bugs.webkit.org/show_bug.cgi?id=207024 Reviewed by Saam Barati. This patch applies the following changes: 1. Prefix Air and B2 dumps with a tierName prefix. The tierName prefix strings are as follows: "FTL ", "DFG ", "b3 ", "Air ", "asm " The choice to use a lowercase "b3" and "asm" with upper case "Air" is deliberate because I found this combination to be easier to read and scan as prefixes of the dump lines. See dump samples below. 2. Make DFG node IDs consistently expressed as D@ e.g. D@104. The definition of the node will be the id followed by a colon e.g. D@104: This makes it easy to search references to this node anywhere in the dump. Make B3 nodes expressed as b@ e.g. b@542. This also makes it searchable since there's now no ambiguity between b@542 and D@542. The choice to use a lowercase "b" and an uppercase "D" is intentional because "b@542" and "d@542" looks too similar, and I prefer to not use too much uppercase. Plus this makes the node consistent in capitalization with the tierName prefixes above of "b3 " and "DFG " respectively. Here's a sample of what the dumps now look like: DFG graph dump: ... 6 55: <-- foo#DFndCW:<0x62d0000b8140, bc#65, Call, known callee: Object: 0x62d000035920 with butterfly 0x0 (Structure %AN:Function), StructureID: 12711, numArgs+this = 1, numFixup = 0, stackOffset = -16 (loc0 maps to loc16)> 3 6 55: D@79:< 3:-> ArithAdd(Int32:Kill:D@95, Int32:D@42, Int32|PureNum|UseAsOther, Int32, CheckOverflow, Exits, bc#71, ExitValid) 4 6 55: D@3: KillStack(MustGen, loc7, W:Stack(loc7), ClobbersExit, bc#71, ExitInvalid) 5 6 55: D@85: MovHint(Check:Untyped:D@79, MustGen, loc7, W:SideState, ClobbersExit, bc#71, ExitInvalid) 6 6 55: D@102:< 1:-> CompareLess(Int32:D@79, Int32:D@89, Boolean|UseAsOther, Bool, Exits, bc#74, ExitValid) 7 6 55: D@104: Branch(KnownBoolean:Kill:D@102, MustGen, T:#1/w:10.000000, F:#7/w:1.000000, W:SideState, bc#74, ExitInvalid) ... B3 graph dump: ... b3 BB#14: ; frequency = 10.000000 b3 Predecessors: #13 b3 Int32 b@531 = CheckAdd(b@10:WarmAny, $1(b@1):WarmAny, b@64:ColdAny, b@10:ColdAny, generator = 0x606000022e80, earlyClobbered = [], lateClobbered = [], usedRegisters = [], ExitsSideways|Reads:Top, D@79) b3 Int32 b@539 = LessThan(b@531, $100(b@578), D@102) b3 Void b@542 = Branch(b@539, Terminal, D@104) b3 Successors: Then:#2, Else:#15 ... Air graph dump: ... Air BB#5: ; frequency = 10.000000 Air Predecessors: #4 Air Move -96(%rbp), %rax, b@531 Air Patch &BranchAdd32(3,ForceLateUseUnlessRecoverable)3, Overflow, $1, %rax, -104(%rbp), -96(%rbp), b@531 Air Branch32 LessThan, %rax, $100, b@542 Air Successors: #1, #6 ... FTL disassembly dump: ... Air BB#5: ; frequency = 10.000000 Air Predecessors: #4 DFG D@42:< 2:-> JSConstant(JS|PureInt, Int32, Int32: 1, bc#0, ExitInvalid) DFG D@79:< 3:-> ArithAdd(Int32:Kill:D@95, Int32:D@42, Int32|PureNum|UseAsOther, Int32, CheckOverflow, Exits, bc#71, ExitValid) b3 Int32 b@1 = Const32(1) b3 Int32 b@531 = CheckAdd(b@10:WarmAny, $1(b@1):WarmAny, b@64:ColdAny, b@10:ColdAny, generator = 0x606000022e80, earlyClobbered = [], lateClobbered = [], usedRegisters = [%rax, %rbx, %rbp, %r12], ExitsSideways|Reads:Top, D@79) Air Move -96(%rbp), %rax, b@531 asm 0x4576b9c04712: mov -0x60(%rbp), %rax Air Patch &BranchAdd32(3,ForceLateUseUnlessRecoverable)3, Overflow, $1, %rax, -104(%rbp), -96(%rbp), b@531 asm 0x4576b9c04716: inc %eax asm 0x4576b9c04718: jo 0x4576b9c04861 DFG D@89:< 1:-> JSConstant(JS|PureNum|UseAsOther, NonBoolInt32, Int32: 100, bc#0, ExitInvalid) DFG D@102:< 1:-> CompareLess(Int32:D@79, Int32:D@89, Boolean|UseAsOther, Bool, Exits, bc#74, ExitValid) DFG D@104: Branch(KnownBoolean:Kill:D@102, MustGen, T:#1/w:10.000000, F:#7/w:1.000000, W:SideState, bc#74, ExitInvalid) b3 Int32 b@578 = Const32(100, D@89) b3 Int32 b@539 = LessThan(b@531, $100(b@578), D@102) b3 Void b@542 = Branch(b@539, Terminal, D@104) Air Branch32 LessThan, %rax, $100, b@542 asm 0x4576b9c0471e: cmp $0x64, %eax asm 0x4576b9c04721: jl 0x4576b9c0462f Air Successors: #1, #6 ... * b3/B3BasicBlock.cpp: (JSC::B3::BasicBlock::deepDump const): * b3/B3Common.cpp: * b3/B3Common.h: * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3Procedure.cpp: (JSC::B3::Procedure::dump const): * b3/B3Value.cpp: * b3/air/AirBasicBlock.cpp: (JSC::B3::Air::BasicBlock::deepDump const): (JSC::B3::Air::BasicBlock::dumpHeader const): (JSC::B3::Air::BasicBlock::dumpFooter const): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::dump const): * b3/air/AirCode.h: * b3/air/AirDisassembler.cpp: (JSC::B3::Air::Disassembler::dump): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * dfg/DFGCommon.cpp: * dfg/DFGCommon.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::dumpBlockHeader): * dfg/DFGNode.cpp: (WTF::printInternal): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLCompile.h: * ftl/FTLState.cpp: (JSC::FTL::State::State): 2020-01-30 Yusuke Suzuki [WTF] Remove PackedIntVector https://bugs.webkit.org/show_bug.cgi?id=207018 Reviewed by Mark Lam. * bytecode/BytecodeBasicBlock.h: 2020-01-30 Yusuke Suzuki [JSC] Remove unnecessary allocations in BytecodeBasicBlock https://bugs.webkit.org/show_bug.cgi?id=206986 Reviewed by Mark Lam. We know that BytecodeBasicBlock itself takes 2MB in Gmail. And each BytecodeBasicBlock has Vector and Vector. BytecodeBasicBlock holds all the offset per bytecode as unsigned in m_offsets. But this offset is only used when reverse iterating a bytecode in a BytecodeBasicBlock. We can hold a length of each bytecode instead, which is much smaller (unsigned v.s. uint8_t). Since each BytecodeBasicBlock has index, we should hold successors in Vector instead of Vector. We are also allocating BytecodeBasicBlock in makeUnique<> and having them in Vector>. But this is not necessary since only BytecodeBasicBlock::compute can modify this vector. We should generate Vector from BytecodeBasicBlock::compute. We are also planning purging BytecodeBasicBlock in UnlinkedCodeBlock if it is not used so much. But this will be done in a separate patch. * bytecode/BytecodeBasicBlock.cpp: (JSC::BytecodeBasicBlock::BytecodeBasicBlock): (JSC::BytecodeBasicBlock::addLength): (JSC::BytecodeBasicBlock::shrinkToFit): (JSC::BytecodeBasicBlock::computeImpl): (JSC::BytecodeBasicBlock::compute): * bytecode/BytecodeBasicBlock.h: (JSC::BytecodeBasicBlock::delta const): (JSC::BytecodeBasicBlock::successors const): (JSC::BytecodeBasicBlock::operator bool const): (JSC::BytecodeBasicBlock::addSuccessor): (JSC::BytecodeBasicBlock::offsets const): Deleted. (JSC::BytecodeBasicBlock:: const): Deleted. (JSC::BytecodeBasicBlock::BytecodeBasicBlock): Deleted. (JSC::BytecodeBasicBlock::addLength): Deleted. * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::BytecodeGeneratorification): * bytecode/BytecodeGraph.h: (JSC::BytecodeGraph::blockContainsBytecodeOffset): (JSC::BytecodeGraph::findBasicBlockForBytecodeOffset): (JSC::BytecodeGraph::findBasicBlockWithLeaderOffset): (JSC::BytecodeGraph::at const): (JSC::BytecodeGraph::operator[] const): (JSC::BytecodeGraph::begin): (JSC::BytecodeGraph::end): (JSC::BytecodeGraph::first): (JSC::BytecodeGraph::last): (JSC::BytecodeGraph::BytecodeGraph): (JSC::BytecodeGraph::begin const): Deleted. (JSC::BytecodeGraph::end const): Deleted. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeIndex): (JSC::BytecodeLivenessAnalysis::computeFullLiveness): (JSC::BytecodeLivenessAnalysis::computeKills): (JSC::BytecodeLivenessAnalysis::dumpResults): * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeIndex): (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock): (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeIndex): (JSC::BytecodeLivenessPropagation::runLivenessFixpoint): * bytecode/InstructionStream.h: (JSC::InstructionStream::MutableRef::operator-> const): (JSC::InstructionStream::MutableRef::ptr const): (JSC::InstructionStream::MutableRef::unwrap const): * bytecode/Opcode.h: * generator/Section.rb: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * llint/LLIntData.cpp: (JSC::LLInt::initialize): * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): 2020-01-30 Alexey Shvayka Incomplete braced quantifiers should be banned in Unicode patterns only https://bugs.webkit.org/show_bug.cgi?id=206776 Reviewed by Darin Adler. This change adds SyntaxError for Unicode patterns, aligning JSC with V8 and SpiderMonkey, and also capitalizes "Unicode" in error messages. Grammar: https://tc39.es/ecma262/#prod-annexB-Term (/u flag precludes the use of ExtendedAtom and thus InvalidBracedQuantifier) * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::parseTokens): 2020-01-30 Yusuke Suzuki [JSC] Make SourceProviderCacheItem small https://bugs.webkit.org/show_bug.cgi?id=206987 Reviewed by Mark Lam. We know this becomes very large when parsing a large script, and it is noticeable in some of RAMification tests. We should use PackedPtr to shrink size of SourceProviderCacheItem. * parser/Parser.h: (JSC::Scope::restoreFromSourceProviderCache): * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::usedVariables const): (JSC::SourceProviderCacheItem::SourceProviderCacheItem): 2020-01-30 Keith Miller Parser needs to restore unary stack state when backtracking https://bugs.webkit.org/show_bug.cgi?id=206972 Reviewed by Saam Barati. Previously we would try to parse possibly stale unary operator stack entries after backtracking from a parse error. This would cause us to think one token was a different token while reparsing after backtracking. Additionally, this patch fixes an issue where the syntax checker would think assignment expressions were resolve expressions. Intrestingly, this was not tested in test262. Lastly, I tried adding some assertions to improve help diagnose when our source text locations are incorrect. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitExpressionInfo): * bytecompiler/NodesCodegen.cpp: (JSC::ThisNode::emitBytecode): (JSC::ResolveNode::emitBytecode): (JSC::EmptyVarExpression::emitBytecode): (JSC::EmptyLetExpression::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::DefineFieldNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::unaryTokenStackDepth const): (JSC::ASTBuilder::setUnaryTokenStackDepth): * parser/Lexer.cpp: (JSC::Lexer::Lexer): * parser/Lexer.h: (JSC::Lexer::setLineNumber): * parser/Nodes.cpp: (JSC::FunctionMetadataNode::operator== const): * parser/Nodes.h: (JSC::ThrowableExpressionData::ThrowableExpressionData): (JSC::ThrowableExpressionData::setExceptionSourceCode): (JSC::ThrowableExpressionData::checkConsistency const): * parser/Parser.cpp: (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseSourceElements): (JSC::Parser::parseModuleSourceElements): (JSC::Parser::parseStatementListItem): (JSC::Parser::parseAssignmentElement): (JSC::Parser::parseForStatement): (JSC::Parser::maybeParseAsyncFunctionDeclarationStatement): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseClass): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseYieldExpression): (JSC::Parser::parseProperty): (JSC::Parser::parseMemberExpression): (JSC::Parser::parseUnaryExpression): * parser/Parser.h: (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext): (JSC::Parser::internalSaveParserState): (JSC::Parser::restoreParserState): (JSC::Parser::internalSaveState): (JSC::Parser::swapSavePointForError): (JSC::Parser::createSavePoint): (JSC::Parser::internalRestoreState): (JSC::Parser::restoreSavePointWithError): (JSC::Parser::restoreSavePoint): (JSC::Parser::createSavePointForError): Deleted. * parser/ParserTokens.h: (JSC::JSTextPosition::JSTextPosition): (JSC::JSTextPosition::checkConsistency): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::operatorStackPop): 2020-01-29 Mark Lam Fix bad assertion in InternalFunctionAllocationProfile::createAllocationStructureFromBase(). https://bugs.webkit.org/show_bug.cgi?id=206981 Reviewed by Keith Miller. InternalFunctionAllocationProfile::createAllocationStructureFromBase() is only called from FunctionRareData::createInternalFunctionAllocationStructureFromBase(), which in turn is only called from InternalFunction::createSubclassStructureSlow(). InternalFunction::createSubclassStructureSlow() only allows a call to FunctionRareData::createInternalFunctionAllocationStructureFromBase() under certain conditions. One of these conditions is that the baseGlobalObject is different than the newTarget's globalObject. InternalFunctionAllocationProfile::createAllocationStructureFromBase() has an ASSERT on the same set of conditions, with one ommission: the one above. This patch fixes the ASSERT by adding the missing condition to match the check in InternalFunction::createSubclassStructureSlow(). * bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase): 2020-01-29 Robin Morisset Remove Options::enableSpectreMitigations https://bugs.webkit.org/show_bug.cgi?id=193885 Reviewed by Saam Barati. From what I remember we decided to remove the spectre-specific mitigations we had tried (in favor of things like process-per-origin). I don't think anyone is using the SpectreGadget we had added for experiments either. So this patch removes the following three options, and all the code that depended on them: - enableSpectreMitigations (was true, only used in one place) - enableSpectreGadgets (was false) - zeroStackFrame (was false, and was an experiment about Spectre variant 4 if I remember correctly) * b3/air/AirCode.cpp: (JSC::B3::Air::defaultPrologueGenerator): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * jit/AssemblyHelpers.h: * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * runtime/OptionsList.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addCallIndirect): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::initCallFrame): 2020-01-29 Devin Rousso Web Inspector: add instrumentation for showing existing Web Animations https://bugs.webkit.org/show_bug.cgi?id=205434 Reviewed by Brian Burg. * inspector/protocol/Animation.json: Add types/commands/events for instrumenting the lifecycle of `Animation` objects, as well as commands for getting the JavaScript wrapper object and the target DOM node. 2020-01-29 Robin Morisset Don't include CCallHelpers.h in B3Procedure.h https://bugs.webkit.org/show_bug.cgi?id=206966 Reviewed by Saam Barati. I verified through -ftime-trace and it massively speeds up a few of the compilation units (e.g. UnifiedSource10.cpp). * b3/B3Procedure.cpp: * b3/B3Procedure.h: * b3/testb3_6.cpp: (testEntrySwitchSimple): (testEntrySwitchNoEntrySwitch): (testEntrySwitchWithCommonPaths): (testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint): (testEntrySwitchLoop): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * wasm/WasmParser.h: 2020-01-29 Justin Michaud Fix small memory regression caused by r206365 https://bugs.webkit.org/show_bug.cgi?id=206557 Reviewed by Yusuke Suzuki. Put StructureRareData::m_giveUpOnObjectToStringValueCache into m_objectToStringValue to prevent increasing StructureRareData's size. We make a special value for the pointer objectToStringCacheGiveUpMarker() to signal that we should not cache the string value. As a result, adding m_transitionOffset does not increase the size of the class. * runtime/Structure.h: * runtime/StructureRareData.cpp: (JSC::StructureRareData::StructureRareData): (JSC::StructureRareData::visitChildren): (JSC::StructureRareData::setObjectToStringValue): (JSC::StructureRareData::clearObjectToStringValue): * runtime/StructureRareData.h: * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::objectToStringValue const): 2020-01-28 Yusuke Suzuki [JSC] Give up IC when unknown structure transition happens https://bugs.webkit.org/show_bug.cgi?id=206846 Reviewed by Mark Lam. When we are creating Put IC for a new property, we grab the old Structure before performing the put. For a custom ::put, our convention is that the implemented ::put should mark the PutPropertySlot as non-cachable. The IC code relies on this in order to work correctly. If we didn't mark it as non-cacheable, a semantic failure can happen. This patch hardens the code against this semantic failure case by giving up trying to cache the IC when the newStructure calculated from oldStructure does not match against the actual structure after the put operation. * jit/Repatch.cpp: (JSC::tryCachePutByID): (JSC::repatchPutByID): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Structure.cpp: (JSC::Structure::flattenDictionaryStructure): * tools/JSDollarVM.cpp: (JSC::functionCreateObjectDoingSideEffectPutWithoutCorrectSlotStatus): (JSC::JSDollarVM::finishCreation): (JSC::JSDollarVM::visitChildren): * tools/JSDollarVM.h: 2020-01-28 Robin Morisset Remove the include of BytecodeGenerator.h in CodeCache.h https://bugs.webkit.org/show_bug.cgi?id=206851 Reviewed by Tadeu Zagallo. This reduces the number of times that BytecodeStructs.h has to be parsed from 33 to 25 times, and unblocks https://bugs.webkit.org/show_bug.cgi?id=206720. * runtime/CodeCache.cpp: (JSC::generateUnlinkedCodeBlockForFunctions): (JSC::generateUnlinkedCodeBlockImpl): (JSC::generateUnlinkedCodeBlock): (JSC::generateUnlinkedCodeBlockForDirectEval): (JSC::recursivelyGenerateUnlinkedCodeBlockForProgram): (JSC::recursivelyGenerateUnlinkedCodeBlockForModuleProgram): * runtime/CodeCache.h: * runtime/Completion.cpp: (JSC::generateProgramBytecode): (JSC::generateModuleBytecode): * runtime/DirectEvalExecutable.cpp: (JSC::DirectEvalExecutable::create): * runtime/JSGlobalObject.cpp: * runtime/VM.cpp: 2020-01-28 Mark Lam Some website needs more stack space. https://bugs.webkit.org/show_bug.cgi?id=206891 Reviewed by Saam Barati. We're bumping the maximum stack usage limit (JSC_maxPerThreadStackUsage) to 5M to give websites a little more stack space when available. The actual useable stack space is still the minimum of JSC_maxPerThreadStackUsage and the stack size that the OS provisions, minus some overhead. * runtime/OptionsList.h: 2020-01-27 Carlos Garcia Campos [GTK] Remote Inspector: add support for service workers targets https://bugs.webkit.org/show_bug.cgi?id=206821 Reviewed by Žan Doberšek. Handle ServiceWorker target type. * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::targetDebuggableType): (Inspector::RemoteInspector::listingForInspectionTarget const): 2020-01-27 Jonathan Bedard Fix OpenSource iphoneos arm64e build https://bugs.webkit.org/show_bug.cgi?id=206703 Reviewed by Yusuke Suzuki. * runtime/MachineContext.h: (JSC::MachineContext::stackPointerImpl): Conditionalize function existence on USE(DARWIN_REGISTER_MACROS). (JSC::MachineContext::stackPointer): Use Darwin's register macros if available. (JSC::MachineContext::setStackPointer): Ditto. (JSC::MachineContext::instructionPointerImpl): Conditionalize function existence on USE(DARWIN_REGISTER_MACROS). (JSC::MachineContext::instructionPointer): Use Darwin's register macros if available. (JSC::MachineContext::setInstructionPointer): Ditto. (JSC::MachineContext::linkRegister): Ditto. (JSC::MachineContext::setLinkRegister): Ditto. (JSC::MachineContext::linkRegisterImpl): Deleted. 2020-01-27 Devin Rousso Web Inspector: unable to evaluate in the isolated world of content scripts injected by safari app extensions https://bugs.webkit.org/show_bug.cgi?id=206110 Reviewed by Timothy Hatcher, Joseph Pecoraro, and Brian Burg. In addition to evaluating in subframe execution contexts, add the ability for Web Inspector to evaluate in non-normal isolated worlds. * inspector/protocol/Runtime.json: Introduce an `ExecutionContextType` enum instead of `isPageContext` so the frontend can decide whether/how to show a picker for that execution context. 2020-01-27 Stephan Szabo Python 3: generate-js-builtins hits SyntaxWarning for "is 0" https://bugs.webkit.org/show_bug.cgi?id=206840 Reviewed by Jonathan Bedard. * Scripts/generate-js-builtins.py: Replace is 0 with == 0 2020-01-27 David Kilzer REGRESSION (r250009): testair crashes in (anonymous namespace)::matchAll Reviewed by Yusuke Suzuki. * b3/air/testair.cpp: ((anonymous namespace)::matchAll): Don't replace `str` in the body of the for loop since `match` references it. 2020-01-27 Ryan Haddad Unreviewed, rolling out r255159. Broke the watchOS build. Reverted changeset: "Fix OpenSource iphoneos arm64e build" https://bugs.webkit.org/show_bug.cgi?id=206703 https://trac.webkit.org/changeset/255159 2020-01-27 Jonathan Bedard Fix OpenSource iphoneos arm64e build https://bugs.webkit.org/show_bug.cgi?id=206703 Reviewed by Yusuke Suzuki. * runtime/MachineContext.h: (JSC::MachineContext::stackPointerImpl): Conditionalize function existence on USE(DARWIN_REGISTER_MACROS). (JSC::MachineContext::stackPointer): Use Darwin's register macros if available. (JSC::MachineContext::setStackPointer): Ditto. (JSC::MachineContext::instructionPointerImpl): Conditionalize function existence on USE(DARWIN_REGISTER_MACROS). (JSC::MachineContext::instructionPointer): Use Darwin's register macros if available. (JSC::MachineContext::setInstructionPointer): Ditto. (JSC::MachineContext::linkRegister): Ditto. (JSC::MachineContext::setLinkRegister): Ditto. (JSC::MachineContext::linkRegisterImpl): Deleted. 2020-01-27 Paulo Matos Remove internal fields in promise assertion for 32bits https://bugs.webkit.org/show_bug.cgi?id=206823 Reviewed by Mark Lam. This assertion was removed for 64bits under bug 201159 but left around in 32bits. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_internal_field): (JSC::JIT::emit_op_put_internal_field): 2020-01-26 Alexey Shvayka Invalid ranges in character classes should be banned in Unicode patterns only https://bugs.webkit.org/show_bug.cgi?id=206768 Reviewed by Darin Adler. In ES5, grammar of CharacterRange was ambiguous, resulting in invalid ranges like /[\d-a]/ being allowed. As of ES2015, invalid ranges are SyntaxError in Unicode patterns, yet still allowed in regular ones to avoid breaking the web. (https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors-annexb) This change adds SyntaxError for Unicode patterns and updates explanatory comments. ErrorCode::CharacterClassOutOfOrder is renamed for consistency with newly added error code and ErrorCode::ParenthesesTypeInvalid. * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate): (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter): (JSC::Yarr::Parser::CharacterClassParserDelegate::atomBuiltInCharacterClass): (JSC::Yarr::Parser::parseCharacterClass): 2020-01-24 Mark Lam Move singleton Intl string locales out of JSGlobalObject. https://bugs.webkit.org/show_bug.cgi?id=206791 Reviewed by Yusuke Suzuki and Andy Wagoner. We were creating an instance of these for each JSGlobalObject when they can be a global singleton since they are always initialized with the same intl data (barring a mid-flight change in intl settings, which we don't support even in the existing code). It turns out that intlPluralRulesAvailableLocales() wasn't called anywhere. IntlPluralRules code currently just uses intlNumberFormatAvailableLocales(). To document that this is intentional, we do the following: 1. have IntlPluralRules code call intlPluralRulesAvailableLocales(), and 2. have intlPluralRulesAvailableLocales() call intlNumberFormatAvailableLocales() for its implementation. See https://bugs.webkit.org/show_bug.cgi?id=206791#c7 and https://bugs.webkit.org/show_bug.cgi?id=206791#c8. In addMissingScriptLocales(), I'm deliberately naming the string with underscores because it's much easier to read pa_PK_String and see that it refers to "pa-PK" as opposed to paPKString. Ditto for zh_CN_String, zh_HK_String, zh_SG_String, and zh_TW_String. * runtime/IntlCollator.cpp: (JSC::IntlCollator::initializeCollator): * runtime/IntlCollatorConstructor.cpp: (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::initializeDateTimeFormat): * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::initializeNumberFormat): * runtime/IntlNumberFormatConstructor.cpp: (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): * runtime/IntlObject.cpp: (JSC::convertICULocaleToBCP47LanguageTag): (JSC::addMissingScriptLocales): (JSC::intlCollatorAvailableLocales): (JSC::intlDateTimeFormatAvailableLocales): (JSC::intlNumberFormatAvailableLocales): (JSC::defaultLocale): * runtime/IntlObject.h: * runtime/IntlPluralRules.cpp: (JSC::IntlPluralRules::initializePluralRules): * runtime/IntlPluralRulesConstructor.cpp: (JSC::IntlPluralRulesConstructorFuncSupportedLocalesOf): * runtime/JSGlobalObject.cpp: (JSC::addMissingScriptLocales): Deleted. (JSC::JSGlobalObject::intlCollatorAvailableLocales): Deleted. (JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales): Deleted. (JSC::JSGlobalObject::intlNumberFormatAvailableLocales): Deleted. (JSC::JSGlobalObject::intlPluralRulesAvailableLocales): Deleted. * runtime/JSGlobalObject.h: 2020-01-24 Mark Lam IntlObject's cached strings should be immortal and safe for concurrent access. https://bugs.webkit.org/show_bug.cgi?id=206779 Reviewed by Yusuke Suzuki. In IntlObject's numberingSystemsForLocale(), we have a never destroyed cachedNumberingSystems which is a singleton vector of Strings which are shared multiple VMs. Hence, the strings in this vector should be a StaticStringImpl so that it will be immortal, and can be access concurrently from multiple VMs on different threads without any ref/deref'ing race issues. * runtime/IntlObject.cpp: (JSC::numberingSystemsForLocale): 2020-01-24 Caio Lima [ARMv7][JIT] Implement checkpoint support https://bugs.webkit.org/show_bug.cgi?id=206611 Reviewed by Yusuke Suzuki. This patch is adding code path to properly support checkpoint on ARMv7. * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): We changed the scratch buffer population to properly handle callee-saved registers on 32-bits. For more details, check comments on source code. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileExit): * jit/GPRInfo.h: (JSC::GPRInfo::toRegister): (JSC::GPRInfo::toIndex): We are adding back `regCS1` to be used as GPRReg on DFG and scratch registers. This was necessary because some code generated by GetByVal IC requires at least 9 registers available. Given that, we also added such register to `dfgCalleeSaveRegisters` set. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitPutByValWithCachedId): * jit/RegisterSet.cpp: (JSC::RegisterSet::dfgCalleeSaveRegisters): * llint/LowLevelInterpreter.asm: 2020-01-24 Keith Miller JSC should produce a module map. https://bugs.webkit.org/show_bug.cgi?id=206717 Reviewed by Mark Lam. * Configurations/JavaScriptCore.xcconfig: * JavaScriptCore.modulemap: 2020-01-24 Commit Queue Unreviewed, rolling out r255052. https://bugs.webkit.org/show_bug.cgi?id=206758 "Broke production builds" (Requested by rmorisset on #webkit). Reverted changeset: "Break the dependency between jsc and DerivedSources" https://bugs.webkit.org/show_bug.cgi?id=206720 https://trac.webkit.org/changeset/255052 2020-01-24 Adrian Perez de Castro Fix various non-unified build issues introduced since r254751 https://bugs.webkit.org/show_bug.cgi?id=206736 Reviewed by Carlos Garcia Campos. * tools/CompilerTimingScope.cpp: Add missing inclusions of wtf/Vector.h and wtf/text/WTFString.h 2020-01-24 Paulo Matos Fix number of callee saved register count on MIPS https://bugs.webkit.org/show_bug.cgi?id=206732 Reviewed by Žan Doberšek. MIPS has been issuing illegal instruction errors due to stack corruption. This is caused by an incorrect number of CalleeSaveRegisterCount that should be set to 3 since r254674. * llint/LowLevelInterpreter.asm: 2020-01-23 Yusuke Suzuki [JSC] DFG OSR exit is not marking CodeBlock::m_hasLinkedOSRExit when the exit target is checkpoint https://bugs.webkit.org/show_bug.cgi?id=206726 Reviewed by Saam Barati. The problem was that DFG OSR exit is not marking CodeBlock::m_hasLinkedOSRExit appropriately when an exit target bytecode-index is a checkpoint. Let's consider the following scenario. 1. The caller CodeBlock "A" has Baseline code. 2. Compile DFG code exiting to the checkpoint of "A". We are not marking "A"'s CodeBlock::m_hasLinkedOSRExit. 3. GC happens and we decide dropping Baseline code for "A" since it is not marked. Switching it to LLInt. 4. However, DFG OSR exit code is compiled by assuming that "A" is Baseline. So LLInt registers are not recovered correctly. 5. Then, exiting to LLInt of "A", LLInt sees that LLInt registers have garbage. In this patch, we correctly set a bit of CodeBlock::m_hasLinkedOSRExit when the exit target is checkpoint. * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): 2020-01-23 Yusuke Suzuki Unreviewed, build fix for Windows https://bugs.webkit.org/show_bug.cgi?id=206706 Definition still existed. * parser/Parser.h: 2020-01-23 Robin Morisset Break the dependency between jsc and DerivedSources https://bugs.webkit.org/show_bug.cgi?id=206720 Reviewed by Mark Lam. According to Tadeu, the slowdown of production builds (by more than 20%) when he landed his bytecode patch was caused by a new dependency of the jsc binary on DerivedSources/, which was needed because of DerivedSources/BytecodeStructs.h being included in CommonSlowPaths.h which is transitively included in jsc.cpp. Now that BytecodeStructs.h is no longer included in CommonSlowPaths.h (see https://bugs.webkit.org/show_bug.cgi?id=206566), I'm trying to break the dependency, to recover from this compile time regression. * Configurations/JSC.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: 2020-01-23 Robin Morisset Remove dead option useFTLTBAA https://bugs.webkit.org/show_bug.cgi?id=206725 Reviewed by Mark Lam. It is likely from when the FTL used LLVM, before B3/Air were written, making this option completely obsolete (and it is currently unused). * runtime/OptionsList.h: 2020-01-23 Robin Morisset Remove dead options "dumpAllDFGNodes"/"showAllDFGNodes" https://bugs.webkit.org/show_bug.cgi?id=204372 Reviewed by Keith Miller. * runtime/OptionsList.h: 2020-01-23 Saam Barati Get rid of didFinishParsing and make parseInner return its results https://bugs.webkit.org/show_bug.cgi?id=206706 Reviewed by Mark Lam and Keith Miller and Yusuke Suzuki. This is paving the way for eagerly parsing immediately invoked functions. Before, we'd just end up setting member fields inside ::didFinishParsing, and then read them out inside ::parse. However, this is not going to work when we are in a world where we're generating AST nodes for more than one function at a time. This patch paves the way for that. * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseInner): (JSC::Parser::didFinishParsing): Deleted. * parser/Parser.h: (JSC::Parser::parse): 2020-01-23 Robin Morisset Don't include BytecodeStructs.h in CommonSlowPaths.h https://bugs.webkit.org/show_bug.cgi?id=206566 Reviewed by Tadeu Zagallo. Simple improvement to compile times. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOSREntry.cpp: * jit/JIT.h: * jit/JITInlines.h: * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: * runtime/CommonSlowPaths.h: * wasm/WasmSlowPaths.cpp: 2020-01-23 Saam Barati OptimizeAssociativeExpressionTrees should reset value owners before running https://bugs.webkit.org/show_bug.cgi?id=206670 Reviewed by Robin Morisset. We have a crash inside OptimizeAssociativeExpressionTrees and we don't know how to reproduce it. Also, based on Mark's auditing of the crash site's assembly, Mark thinks we're crashing on a "currupt" basic block. After I audited the code, I saw that we rely on value owners in this phase. However, we don't actually reset them before running the phase. This patch adds that as a speculative fix for the crash we're seeing. * b3/B3OptimizeAssociativeExpressionTrees.cpp: (JSC::B3::OptimizeAssociativeExpressionTrees::run): 2020-01-23 Yusuke Suzuki Unreviewed, fix calculation of kindBits https://bugs.webkit.org/show_bug.cgi?id=206650 * bytecode/Operands.h: 2020-01-22 Yusuke Suzuki [JSC] Bits from Operand should fit in bits reserved in AbstractHeap's Payload https://bugs.webkit.org/show_bug.cgi?id=206619 Reviewed by Keith Miller. We extended JSC::Operand to have an additional field representing OperandKind. However, we have restriction in DFG::AbstractHeap's Payload that Operand's raw bits format need to fit in reserved bits in Payload's raw bits format, 49 bits. Since we ordered fields of Operand "m_kind" and "m_operand", in little endian architecture, raw bits format of Operand can exceed 49 bits if m_operand is large enough. This patch fixes the order to ensure that Operand's raw bit format always fits in 49 bits. * bytecode/Operands.h: (JSC::Operand::Operand): (JSC::Operand::asBits const): * dfg/DFGAbstractHeap.h: 2020-01-22 Mark Lam Restore nullification of DFG::Plan::m_vm when the plan is cancelled. https://bugs.webkit.org/show_bug.cgi?id=206633 Reviewed by Robin Morisset. In r253243, I replaced the nullification of Plan::m_vm in Plan::cancel() with code to decorate the m_vm pointer with a nuke bit. The thinking is that keeping the VM pointer in nuked form allows us to do certain assertions, as well as implementing code in support of keeping Boxs alive. It is only correct to use the nuked VM pointer if and only if the VM is guaranteed to outlive the Plan. r253243 guarantees this condition. In r254464, I replaced the use of Box with CacheableIdentifier. This obviated all the support code added above, and rolled out most of it. However, I opted to keep the nuked VM pointer in the DFG::Plan to as a debugging aid (it's nice to be able to know which VM the Plan came from). However, r254464 also undid the guarantee that the VM will outlive the Plan. As a result, a nuked VM pointer is no longer guaranteed to point to a valid VM. Some worker layout tests, run on an ASAN build, detected that the pointer is pointing to an already freed VM and failed with a crash. This patch fixes this issue by completely reverting the nuked VM pointer code, and restores nullification of the m_vm pointer in Plan::cancel(). * dfg/DFGPlan.cpp: (JSC::DFG::Plan::computeCompileTimes const): (JSC::DFG::Plan::cancel): * dfg/DFGPlan.h: (JSC::DFG::Plan::vm const): (JSC::DFG::Plan::unnukedVM const): Deleted. (JSC::DFG::Plan::nuke): Deleted. (JSC::DFG::Plan::unnuke): Deleted. 2020-01-22 Keith Miller Remove DFGAbstractHeap::typeInfoType since it's immutable https://bugs.webkit.org/show_bug.cgi?id=206638 Reviewed by Yusuke Suzuki. * dfg/DFGAbstractHeap.h: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2020-01-22 Keith Miller InternalField and CheckNeutered DFG nodes are not always safe to execute https://bugs.webkit.org/show_bug.cgi?id=206632 Reviewed by Saam Barati. We currently mark (Get/Set)InternalField/CheckNeutered nodes as safe to execute everywhere. However, GetInternalField, etc. rely on a proof that the cell passed to it is a subclass of InteralFieldObject. This combination means we may hoist the nodes past the check guarding them. Also, remove a bogus assertion that we will have proven the value passed to CheckNeutered is a TypedArray. It's not valid to require that AI preserve a precise model of all invariants since phases can make changes that AI doesn't understand. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckNeutered): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCheckNeutered): 2020-01-22 Saam Barati Add an option for logging total phase times https://bugs.webkit.org/show_bug.cgi?id=206623 Reviewed by Robin Morisset and Keith Miller. * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * jsc.cpp: (runJSC): * runtime/OptionsList.h: * tools/CompilerTimingScope.cpp: (JSC::CompilerTimingScope::CompilerTimingScope): (JSC::CompilerTimingScope::~CompilerTimingScope): (JSC::logTotalPhaseTimes): * tools/CompilerTimingScope.h: 2020-01-22 Caio Lima [32-bits][JIT] Fix build issues. https://bugs.webkit.org/show_bug.cgi?id=206603 Reviewed by Yusuke Suzuki. This patch is adjusting places to use VirtualRegister instead of offset directly, to make 32-bit JIT compilable again. Original authors of this patch are Paulo Matos and Guillaume Emont. * jit/JIT.h: * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emitBinaryDoubleOp): * jit/JITCall32_64.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::emit_op_ret): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): * jit/JITInlines.h: (JSC::JIT::emitLoadTag): (JSC::JIT::emitLoadPayload): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitJumpSlowCaseIfNotJSCell): (JSC::JIT::getOperandConstantInt): (JSC::JIT::emitGet): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jundefined_or_null): (JSC::JIT::emit_op_jnundefined_or_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_neq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_numeric): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emitResolveClosure): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emitLoadWithStructureCheck): (JSC::JIT::emitGetClosureVar): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emitPutGlobalVariable): (JSC::JIT::emitPutGlobalVariableIndirect): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emit_op_get_internal_field): (JSC::JIT::emit_op_put_internal_field): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::emitJumpIfNotJSCell): (JSC::JSInterfaceJIT::emitLoadInt32): (JSC::JSInterfaceJIT::emitLoadDouble): 2020-01-22 Caio Lima [ARMv7] Assembler is generating wrong instruction for ldr r2, [r3, #7] https://bugs.webkit.org/show_bug.cgi?id=206231 Reviewed by Mark Lam. When generating code for `ldr` on ARMv7, we were encoding immediates not multiple of 4 using Encoding T1, which only accepts multiple of 4 as immediates. This patch fixes such issue and allow us generate proper code when offset imemdiates are not multiple of 4. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::ldr): 2020-01-22 Yusuke Suzuki [JSC] Add CheckArrayOrEmpty to handle the case when hoisting CheckArray for places where input can be empty https://bugs.webkit.org/show_bug.cgi?id=206571 Reviewed by Saam Barati. Since we hoist CheckArray too in DFGTypeCheckHoistingPhase, we have the same problem to CheckStructureOrEmpty: we could insert CheckArray where the input can include Empty. We should have CheckArrayOrEmpty as we have CheckStructureOrEmpty for CheckStructure: CheckArrayOrEmpty accepts empty or cell with specified array-modes. * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::filterArrayModes): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): (JSC::DFG::AbstractInterpreter::filterArrayModes): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::filterArrayModes): * dfg/DFGAbstractValue.h: * 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::convertCheckArrayOrEmptyToCheckArray): (JSC::DFG::Node::hasArrayMode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArray): * 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::compileCheckArrayOrEmpty): 2020-01-22 Yusuke Suzuki [JSC] Attempt to fix BytecodeIndex handling in 32bit https://bugs.webkit.org/show_bug.cgi?id=206577 Reviewed by Keith Miller. This patch mechanically lists up places using Instruction* as BytecodeIndex and fixes it, since 32bit also starts using an offset as BytecodeIndex. This patch also fixes several places where LLInt PB is not handled correctly in 32bit after we start using PB register even in 32bit. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::bytecodeIndexFromCallSiteIndex): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * jit/JITCall32_64.cpp: (JSC::JIT::compileOpCall): * jit/JITInlines.h: (JSC::JIT::updateTopCallFrame): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emit_op_in_by_id): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): * runtime/SamplingProfiler.cpp: (JSC::tryGetBytecodeIndex): (JSC::SamplingProfiler::processUnverifiedStackTraces): 2020-01-22 Saam Barati Throw away baseline code if there is an optimized replacement https://bugs.webkit.org/show_bug.cgi?id=202503 Reviewed by Yusuke Suzuki. This patch's goal is to help us save JIT executable memory by throwing away baseline code when it has an optimized replacement. To make it easy to reason about, we do this when finalizing a GC, when the CodeBlock is not on the stack, and when no OSR exits are linked to jump to the baseline code. Also, as a measure to combat a performance regression, we only throw away code on the second GC cycle in which it is eligible for this. When we downgrade Baseline to LLInt, we also throw away all JIT data and unlink all incoming calls. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::resetJITData): (JSC::CodeBlock::optimizedReplacement): (JSC::CodeBlock::hasOptimizedReplacement): (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): (JSC::DFG::adjustAndJumpToTarget): * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::isCurrentlyExecuting): * heap/CodeBlockSet.h: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): (JSC::Heap::runEndPhase): 2020-01-21 Ross Kirsling [JSC] Date parse logic should be less redundant https://bugs.webkit.org/show_bug.cgi?id=206560 Reviewed by Darin Adler. Our date parsing logic is doing an excessive amount of NaN-checking; let's streamline this by having one JSC-side helper function instead of two. * runtime/JSDateMath.cpp: (JSC::parseDate): (JSC::parseDateFromNullTerminatedCharacters): Deleted. (JSC::parseES5DateFromNullTerminatedCharacters): Deleted. 2020-01-21 Rob Buis Add build flag for stale-while-revalidate https://bugs.webkit.org/show_bug.cgi?id=204169 Reviewed by Youenn Fablet. * Configurations/FeatureDefines.xcconfig: 2020-01-21 Tadeu Zagallo Object allocation sinking is missing PutHint for sunken allocations https://bugs.webkit.org/show_bug.cgi?id=203799 Reviewed by Saam Barati. Consider the following graph: Block #0: 1: PhantomCreateActivation() 2: PhantomNewFunction() PutHint(@2, @1, FunctionActivationPLoc) Branch(#1, #2) Block #1: 3: MaterializeCreateActivation() PutHint(@2, @3, FunctionActivationPLoc) Upsilon(@3, ^5) Jump(#3) Block #2: 4: MaterializeCreateActivation() PutHint(@2, @4, FunctionActivationPLoc) Upsilon(@4, ^5) Jump(#3) Block #3: 5: Phi() ExitOK() On Block #3, we need to emit a PutHint after the Phi, since we might exit after it. However, object allocation sinking skipped this Phi because it was checking whether the base of the location that caused us to create this Phi (@2) was live, but it's dead in the graph (there are no pointers to it). The issue is that, even though there are no pointers to the base, the location `PromotedHeapLocation(@2, FunctionActivationPLoc)` is still live, so we should PutHint to it. We fix it by checking for liveness of the location rather than its base. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2020-01-21 Mark Lam Rename JSPromiseFields abstract heap to JSInternalFields. https://bugs.webkit.org/show_bug.cgi?id=206518 Reviewed by Yusuke Suzuki. This is because it is used for all internal fields, not just the ones in JSPromise. * dfg/DFGAbstractHeap.h: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2020-01-17 Sam Weinig Platform.h is out of control Part 8: Macros are used inconsistently https://bugs.webkit.org/show_bug.cgi?id=206425 Reviewed by Darin Adler. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::cacheFlush): (JSC::ARM64Assembler::xOrSp): (JSC::ARM64Assembler::xOrZr): * assembler/ARM64Registers.h: * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::cacheFlush): * assembler/ARMv7Registers.h: * assembler/AssemblerCommon.h: (JSC::isDarwin): * b3/air/AirCCallingConvention.cpp: * jit/ExecutableAllocator.h: * jit/ThunkGenerators.cpp: * jsc.cpp: * runtime/MathCommon.cpp: Use OS(DARWIN) more consistently for darwin level functionality. * bytecode/CodeOrigin.h: * runtime/JSString.h: Update to use OS_CONSTANT. * disassembler/ARM64/A64DOpcode.cpp: * disassembler/ARM64Disassembler.cpp: * disassembler/UDis86Disassembler.cpp: * disassembler/UDis86Disassembler.h: * disassembler/X86Disassembler.cpp: * disassembler/udis86/udis86.c: * disassembler/udis86/udis86_decode.c: * disassembler/udis86/udis86_itab_holder.c: * disassembler/udis86/udis86_syn-att.c: * disassembler/udis86/udis86_syn-intel.c: * disassembler/udis86/udis86_syn.c: * interpreter/Interpreter.cpp: * interpreter/Interpreter.h: * interpreter/InterpreterInlines.h: (JSC::Interpreter::getOpcodeID): * llint/LowLevelInterpreter.cpp: * tools/SigillCrashAnalyzer.cpp: Switch to using ENABLE rather than USE for features internal to WebKit 2020-01-20 Gus Caplan Remove own toString from NativeError prototype https://bugs.webkit.org/show_bug.cgi?id=204629 Reviewed by Ross Kirsling. NativeError prototypes are expected to inherit toString from Error.prototype. See https://github.com/tc39/ecma262/issues/1794 for additional details. * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototypeBase::ErrorPrototypeBase): (JSC::ErrorPrototypeBase::finishCreation): (JSC::ErrorPrototype::ErrorPrototype): (JSC::ErrorPrototype::create): Deleted. (JSC::ErrorPrototype::finishCreation): Deleted. * runtime/ErrorPrototype.h: (JSC::ErrorPrototype::createStructure): Deleted. * runtime/NativeErrorPrototype.cpp: (JSC::NativeErrorPrototype::NativeErrorPrototype): * runtime/NativeErrorPrototype.h: 2020-01-20 David Kilzer Fix missing header guards and clean up empty files in bmalloc, WTF, JavaScriptCore Reviewed by Darin Adler. * dfg/DFGPrePostNumbering.cpp: Remove empty file. * dfg/DFGPrePostNumbering.h: Remove empty file. * runtime/OptionEntry.h: Remove empty file. * API/JSCallbackObjectFunctions.h: * b3/testb3.h: * heap/IsoInlinedHeapCellType.h: * wasm/WasmGeneratorTraits.h: - Add #pragma once. 2020-01-18 Caitlin Potter [JSC] add DFG/FTL support for op_to_property_key https://bugs.webkit.org/show_bug.cgi?id=206368 Reviewed by Saam Barati. Implement DFG/FTL support for the op_to_property_key opcode. This operates similar to the LLInt and base JIT implementations, in which we avoid invoking the full ToPropertyKey operation if the source operand is already a String or Symbol at runtime. If DFG/FTL are confident the value will be a String or Symbol at compile time, the operation is omitted entirely in the final graph. * 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/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::convertToToString): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileToPrimitive): (JSC::DFG::SpeculativeJIT::compileToPropertyKey): * 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::compileToPropertyKey): 2020-01-17 Saam Barati Air O0 should have better stack allocation https://bugs.webkit.org/show_bug.cgi?id=206436 Reviewed by Tadeu Zagallo. This patch adds a simple stack slot allocator to Air O0 to make code use smaller stack frames. The huge stack frames from the old stack allocator were leading to stack overflows in some programs. Before, each Tmp got its own stack slot. The new allocator works similar to O0's register allocator. This stack allocator linearizes the program and uses live range end as an opportunity to place the stack slot on a free list of available stack slots. This patch also fixes an issue in our linearization code where the head of a block and the tail of another block would share the same linearization index. This didn't matter for register allocation, but does matter for the stack allocator. So "live at head", and "live at tail" now get their own linearization index. * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::buildLiveRanges): (JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration): (JSC::B3::Air::GenerateAndAllocateRegisters::generate): * b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: * b3/air/AirLiveness.h: 2020-01-17 David Kilzer [JSC] Add missing header guards Reviewed by Mark Lam. * heap/IsoHeapCellType.h: * wasm/WasmFaultSignalHandler.h: - Add #pragma once header guard. 2020-01-17 Mark Lam JSModuleLoader's printableModuleKey() should never throw. https://bugs.webkit.org/show_bug.cgi?id=206461 Reviewed by Michael Saboff. Hence, it should be using a CatchScope instead of a ThrowScope. * runtime/JSModuleLoader.cpp: (JSC::printableModuleKey): 2020-01-17 Justin Michaud Separate storage of Structure::m_offset into transition and max offset https://bugs.webkit.org/show_bug.cgi?id=206365 Reviewed by Saam Barati. Right now, deleteProperty/removePropertyTransition causes a structure transition to uncacheable dictionary. Other transitions assume that the transition offset (m_offset) is monotonically increasing. In order to support structure transitions for deletion that do not involve turning into a dictionary (), we first need to separate the transition offset (the offset of the property that was added/deleted) from the maximum offset. For example, suppose we have the following operations: Structure 1 (pinned property table, transitionOffset = _, maxOffset = 2): x y z (delete y, assuming that deletion transitions have been added) Structure 2 (transitionOffset = 1, maxOffset = 2): x _ z (add w) Structure 3 (transitionOffset = 1, maxOffset = 2): x w z Note that without splitting the two, Structures 2/3 would be impossible to represent. This change: We split the existing Structure::m_offset into two 16-bit fields, transitionOffset and maxOffset, and put them in 32-bit rare data fields if they overflow. We also rename _inPrevious fields to transition_ and lastOffset to maxOffset to make the code more clear. * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createStructure): * runtime/JSObject.cpp: (JSC::JSObject::markAuxiliaryAndVisitOutOfLineProperties): (JSC::JSObject::visitButterflyImpl): * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSObject::prepareToPutDirectWithoutTransition): * runtime/ObjectInitializationScope.cpp: (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized): * runtime/PropertyOffset.h: (JSC::numberOfOutOfLineSlotsForMaxOffset): (JSC::numberOfSlotsForMaxOffset): (JSC::numberOfOutOfLineSlotsForLastOffset): Deleted. (JSC::numberOfSlotsForLastOffset): Deleted. * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains const): (JSC::StructureTransitionTable::get const): (JSC::StructureTransitionTable::add): (JSC::Structure::Structure): (JSC::Structure::create): (JSC::Structure::materializePropertyTable): (JSC::Structure::addPropertyTransitionToExistingStructureImpl): (JSC::Structure::addNewPropertyTransition): (JSC::Structure::changePrototypeTransition): (JSC::Structure::attributeChangeTransition): (JSC::Structure::toDictionaryTransition): (JSC::Structure::nonPropertyTransitionSlow): (JSC::Structure::flattenDictionaryStructure): (JSC::Structure::pin): (JSC::Structure::pinForCaching): (JSC::Structure::add): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::forEachPropertyConcurrently): (JSC::Structure::checkOffsetConsistency const): (JSC::Structure::add): * runtime/StructureRareData.cpp: (JSC::StructureRareData::StructureRareData): * runtime/StructureRareData.h: 2020-01-17 Alexey Shvayka JSON.parse should lookup prototype chains during revival https://bugs.webkit.org/show_bug.cgi?id=205769 Reviewed by Saam Barati. This patch makes JSON.parse use [[Get]] instead of [[GetOwnProperty]] during revival, aligning JSC with the spec (step 1 of https://tc39.es/ecma262/#sec-internalizejsonproperty), SpiderMonkey, and V8. User-provided `reviver` can delete properties that are not yet inspected by itself, making usage [[GetOwnProperty]] non-compliant to the spec. * runtime/JSONObject.cpp: (JSC::Walker::walk): 2020-01-17 Caio Lima Bytecode checkpoints break 32bit tests https://bugs.webkit.org/show_bug.cgi?id=206404 Unreviewed. * llint/LowLevelInterpreter32_64.asm: Reverting change introduced by r254735 that makes 32-bit codes crash when calling into LLInt slow path. 2020-01-16 Robin Morisset [ESNext] Enables a way to throw an error on ByteCodeGenerator step https://bugs.webkit.org/show_bug.cgi?id=180139 Reviewed by Mark Lam. This is a minimal fix that only deals with overly huge BigInts. A more thorough solution is rather low priority (since it has neither securities nor performance impact). * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addBigIntConstant): * bytecompiler/NodesCodegen.cpp: (JSC::ConstantNode::emitBytecode): * runtime/JSBigInt.cpp: (JSC::JSBigInt::parseInt): 2020-01-16 Keith Miller Reland bytecode checkpoints since bugs have been fixed https://bugs.webkit.org/show_bug.cgi?id=206361 Unreviewed, reland. The watch bugs have been fixed by https://trac.webkit.org/changeset/254674 * CMakeLists.txt: * DerivedSources-input.xcfilelist: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssemblerCodeRef.h: * assembler/ProbeFrame.h: (JSC::Probe::Frame::operand): (JSC::Probe::Frame::setOperand): * b3/testb3.h: (populateWithInterestingValues): (floatingPointOperands): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/AccessCaseSnippetParams.cpp: (JSC::SlowPathCallGeneratorWithArguments::generateImpl): * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumperBase::dumpValue): (JSC::BytecodeDumper::registerName const): (JSC::BytecodeDumper::constantName const): (JSC::Wasm::BytecodeDumper::constantName const): * bytecode/BytecodeDumper.h: * bytecode/BytecodeIndex.cpp: (JSC::BytecodeIndex::dump const): * bytecode/BytecodeIndex.h: (JSC::BytecodeIndex::BytecodeIndex): (JSC::BytecodeIndex::offset const): (JSC::BytecodeIndex::checkpoint const): (JSC::BytecodeIndex::asBits const): (JSC::BytecodeIndex::hash const): (JSC::BytecodeIndex::operator bool const): (JSC::BytecodeIndex::pack): (JSC::BytecodeIndex::fromBits): * bytecode/BytecodeList.rb: * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::enumValuesEqualAsIntegral): (JSC::tmpLivenessForCheckpoint): * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::virtualRegisterIsAlwaysLive): (JSC::virtualRegisterThatIsNotAlwaysLiveIsLive): (JSC::virtualRegisterIsLive): (JSC::operandIsAlwaysLive): Deleted. (JSC::operandThatIsNotAlwaysLiveIsLive): Deleted. (JSC::operandIsLive): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::bytecodeIndexForExit const): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndexSlow): (JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness): * bytecode/CodeBlock.h: (JSC::CodeBlock::numTmps const): (JSC::CodeBlock::isKnownNotImmediate): (JSC::CodeBlock::isTemporaryRegister): (JSC::CodeBlock::constantRegister): (JSC::CodeBlock::getConstant const): (JSC::CodeBlock::constantSourceCodeRepresentation const): (JSC::CodeBlock::replaceConstant): (JSC::CodeBlock::isTemporaryRegisterIndex): Deleted. (JSC::CodeBlock::isConstantRegisterIndex): Deleted. * bytecode/CodeOrigin.h: * bytecode/FullBytecodeLiveness.h: (JSC::FullBytecodeLiveness::virtualRegisterIsLive const): (JSC::FullBytecodeLiveness::operandIsLive const): Deleted. * bytecode/InlineCallFrame.h: (JSC::InlineCallFrame::InlineCallFrame): (JSC::InlineCallFrame::setTmpOffset): (JSC::CodeOrigin::walkUpInlineStack const): (JSC::CodeOrigin::inlineStackContainsActiveCheckpoint const): (JSC::remapOperand): (JSC::unmapOperand): (JSC::CodeOrigin::walkUpInlineStack): Deleted. * bytecode/LazyOperandValueProfile.h: (JSC::LazyOperandValueProfileKey::LazyOperandValueProfileKey): (JSC::LazyOperandValueProfileKey::hash const): (JSC::LazyOperandValueProfileKey::operand const): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::fromLazyOperand): (JSC::MethodOfGettingAValueProfile::emitReportValue const): (JSC::MethodOfGettingAValueProfile::reportValue): * bytecode/MethodOfGettingAValueProfile.h: * bytecode/Operands.h: (JSC::Operand::Operand): (JSC::Operand::tmp): (JSC::Operand::kind const): (JSC::Operand::value const): (JSC::Operand::virtualRegister const): (JSC::Operand::asBits const): (JSC::Operand::isTmp const): (JSC::Operand::isArgument const): (JSC::Operand::isLocal const): (JSC::Operand::isHeader const): (JSC::Operand::isConstant const): (JSC::Operand::toArgument const): (JSC::Operand::toLocal const): (JSC::Operand::operator== const): (JSC::Operand::isValid const): (JSC::Operand::fromBits): (JSC::Operands::Operands): (JSC::Operands::numberOfLocals const): (JSC::Operands::numberOfTmps const): (JSC::Operands::tmpIndex const): (JSC::Operands::argumentIndex const): (JSC::Operands::localIndex const): (JSC::Operands::tmp): (JSC::Operands::tmp const): (JSC::Operands::argument): (JSC::Operands::argument const): (JSC::Operands::local): (JSC::Operands::local const): (JSC::Operands::sizeFor const): (JSC::Operands::atFor): (JSC::Operands::atFor const): (JSC::Operands::ensureLocals): (JSC::Operands::ensureTmps): (JSC::Operands::getForOperandIndex): (JSC::Operands::getForOperandIndex const): (JSC::Operands::operandIndex const): (JSC::Operands::operand): (JSC::Operands::operand const): (JSC::Operands::hasOperand const): (JSC::Operands::setOperand): (JSC::Operands::at const): (JSC::Operands::at): (JSC::Operands::operator[] const): (JSC::Operands::operator[]): (JSC::Operands::operandForIndex const): (JSC::Operands::operator== const): (JSC::Operands::isArgument const): Deleted. (JSC::Operands::isLocal const): Deleted. (JSC::Operands::virtualRegisterForIndex const): Deleted. (JSC::Operands::setOperandFirstTime): Deleted. * bytecode/OperandsInlines.h: (JSC::Operand::dump const): (JSC::Operands::dumpInContext const): (JSC::Operands::dump const): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::hasCheckpoints const): (JSC::UnlinkedCodeBlock::setHasCheckpoints): (JSC::UnlinkedCodeBlock::constantRegister const): (JSC::UnlinkedCodeBlock::getConstant const): (JSC::UnlinkedCodeBlock::isConstantRegisterIndex const): Deleted. * bytecode/ValueProfile.h: (JSC::ValueProfileAndVirtualRegisterBuffer::ValueProfileAndVirtualRegisterBuffer): (JSC::ValueProfileAndVirtualRegisterBuffer::~ValueProfileAndVirtualRegisterBuffer): (JSC::ValueProfileAndOperandBuffer::ValueProfileAndOperandBuffer): Deleted. (JSC::ValueProfileAndOperandBuffer::~ValueProfileAndOperandBuffer): Deleted. (JSC::ValueProfileAndOperandBuffer::forEach): Deleted. * bytecode/ValueRecovery.cpp: (JSC::ValueRecovery::recover const): * bytecode/ValueRecovery.h: * bytecode/VirtualRegister.h: (JSC::virtualRegisterIsLocal): (JSC::virtualRegisterIsArgument): (JSC::VirtualRegister::VirtualRegister): (JSC::VirtualRegister::isValid const): (JSC::VirtualRegister::isLocal const): (JSC::VirtualRegister::isArgument const): (JSC::VirtualRegister::isConstant const): (JSC::VirtualRegister::toConstantIndex const): (JSC::operandIsLocal): Deleted. (JSC::operandIsArgument): Deleted. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::initializeNextParameter): (JSC::BytecodeGenerator::initializeParameters): (JSC::BytecodeGenerator::emitEqualityOpImpl): (JSC::BytecodeGenerator::emitCallVarargs): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::setUsesCheckpoints): * bytecompiler/RegisterID.h: (JSC::RegisterID::setIndex): * dfg/DFGAbstractHeap.cpp: (JSC::DFG::AbstractHeap::Payload::dumpAsOperand const): (JSC::DFG::AbstractHeap::dump const): * dfg/DFGAbstractHeap.h: (JSC::DFG::AbstractHeap::Payload::Payload): (JSC::DFG::AbstractHeap::AbstractHeap): (JSC::DFG::AbstractHeap::operand const): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentPosition.h: (JSC::DFG::ArgumentPosition::dump): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArgumentsUtilities.cpp: (JSC::DFG::argumentsInvolveStackSlot): (JSC::DFG::emitCodeToGetArgumentsArrayLength): * dfg/DFGArgumentsUtilities.h: * dfg/DFGAtTailAbstractState.h: (JSC::DFG::AtTailAbstractState::operand): * dfg/DFGAvailabilityMap.cpp: (JSC::DFG::AvailabilityMap::pruneByLiveness): * dfg/DFGAvailabilityMap.h: (JSC::DFG::AvailabilityMap::closeStartingWithLocal): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::BasicBlock): (JSC::DFG::BasicBlock::ensureTmps): * dfg/DFGBasicBlock.h: * dfg/DFGBlockInsertionSet.cpp: (JSC::DFG::BlockInsertionSet::insert): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ByteCodeParser): (JSC::DFG::ByteCodeParser::ensureTmps): (JSC::DFG::ByteCodeParser::progressToNextCheckpoint): (JSC::DFG::ByteCodeParser::newVariableAccessData): (JSC::DFG::ByteCodeParser::getDirect): (JSC::DFG::ByteCodeParser::get): (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getLocalOrTmp): (JSC::DFG::ByteCodeParser::setLocalOrTmp): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::findArgumentPosition): (JSC::DFG::ByteCodeParser::flushImpl): (JSC::DFG::ByteCodeParser::flushForTerminalImpl): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::flushDirect): (JSC::DFG::ByteCodeParser::addFlushOrPhantomLocal): (JSC::DFG::ByteCodeParser::phantomLocalDirect): (JSC::DFG::ByteCodeParser::flushForTerminal): (JSC::DFG::ByteCodeParser::addToGraph): (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand const): (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute): (JSC::DFG::ByteCodeParser::allocateTargetableBlock): (JSC::DFG::ByteCodeParser::allocateUntargetableBlock): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parse): (JSC::DFG::ByteCodeParser::getLocal): Deleted. (JSC::DFG::ByteCodeParser::setLocal): Deleted. * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::injectOSR): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::run): (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocal): (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocal): (JSC::DFG::CPSRethreadingPhase::canonicalizeSet): (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock): (JSC::DFG::CPSRethreadingPhase::propagatePhis): (JSC::DFG::CPSRethreadingPhase::phiStackFor): * dfg/DFGCSEPhase.cpp: * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCombinedLiveness.cpp: (JSC::DFG::addBytecodeLiveness): * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::addCodeOrigin): (JSC::DFG::CommonData::addUniqueCallSiteIndex): (JSC::DFG::CommonData::lastCallSite const): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGForAllKills.h: (JSC::DFG::forAllKilledOperands): (JSC::DFG::forAllKilledNodesAtNodeIndex): (JSC::DFG::forAllKillsInBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::dumpBlockHeader): (JSC::DFG::Graph::substituteGetLocal): (JSC::DFG::Graph::isLiveInBytecode): (JSC::DFG::Graph::localsAndTmpsLiveInBytecode): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): (JSC::DFG::Graph::localsLiveInBytecode): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::forAllLocalsAndTmpsLiveInBytecode): (JSC::DFG::Graph::forAllLiveInBytecode): (JSC::DFG::Graph::forAllLocalsLiveInBytecode): Deleted. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::InPlaceAbstractState): * dfg/DFGInPlaceAbstractState.h: (JSC::DFG::InPlaceAbstractState::operand): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::emitStoreCallSiteIndex): * dfg/DFGLiveCatchVariablePreservationPhase.cpp: (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation): (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch): (JSC::DFG::LiveCatchVariablePreservationPhase::newVariableAccessData): * dfg/DFGMovHintRemovalPhase.cpp: * dfg/DFGNode.h: (JSC::DFG::StackAccessData::StackAccessData): (JSC::DFG::Node::hasArgumentsChild): (JSC::DFG::Node::argumentsChild): (JSC::DFG::Node::operand): (JSC::DFG::Node::hasUnlinkedOperand): (JSC::DFG::Node::unlinkedOperand): (JSC::DFG::Node::hasLoadVarargsData): (JSC::DFG::Node::local): Deleted. (JSC::DFG::Node::hasUnlinkedLocal): Deleted. (JSC::DFG::Node::unlinkedLocal): Deleted. * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): (JSC::DFG::prepareCatchOSREntry): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::emitRestoreArguments): (JSC::DFG::OSRExit::compileExit): (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: * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::isExitingToCheckpointHandler const): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGOpInfo.h: (JSC::DFG::OpInfo::OpInfo): * dfg/DFGOperations.cpp: * dfg/DFGPhantomInsertionPhase.cpp: * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::read): (JSC::DFG::PreciseLocalClobberizeAdaptor::write): (JSC::DFG::PreciseLocalClobberizeAdaptor::def): (JSC::DFG::PreciseLocalClobberizeAdaptor::callIfAppropriate): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGPutStackSinkingPhase.cpp: * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::compileVarargsLength): (JSC::DFG::SpeculativeJIT::compileLoadVarargs): (JSC::DFG::SpeculativeJIT::compileForwardVarargs): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::recordSetLocal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): (JSC::DFG::StackLayoutPhase::assign): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitThunkGenerator): Deleted. * dfg/DFGThunks.h: * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries): * dfg/DFGValidate.cpp: * dfg/DFGVarargsForwardingPhase.cpp: * dfg/DFGVariableAccessData.cpp: (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): (JSC::DFG::VariableAccessData::tallyVotesForShouldUseDoubleFormat): (JSC::DFG::VariableAccessData::couldRepresentInt52Impl): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::operand): (JSC::DFG::VariableAccessData::local): Deleted. * dfg/DFGVariableEvent.cpp: (JSC::DFG::VariableEvent::dump const): * dfg/DFGVariableEvent.h: (JSC::DFG::VariableEvent::spill): (JSC::DFG::VariableEvent::setLocal): (JSC::DFG::VariableEvent::movHint): (JSC::DFG::VariableEvent::spillRegister const): (JSC::DFG::VariableEvent::operand const): (JSC::DFG::VariableEvent::bytecodeRegister const): Deleted. * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::logEvent): (JSC::DFG::VariableEventStream::reconstruct const): * dfg/DFGVariableEventStream.h: (JSC::DFG::VariableEventStream::appendAndLog): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLForOSREntryJITCode.cpp: (JSC::FTL::ForOSREntryJITCode::ForOSREntryJITCode): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileExtractOSREntryLocal): (JSC::FTL::DFG::LowerDFGToB3::compileGetStack): (JSC::FTL::DFG::LowerDFGToB3::compileGetCallee): (JSC::FTL::DFG::LowerDFGToB3::compileSetCallee): (JSC::FTL::DFG::LowerDFGToB3::compileSetArgumentCountIncludingThis): (JSC::FTL::DFG::LowerDFGToB3::compileVarargsLength): (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): (JSC::FTL::DFG::LowerDFGToB3::getSpreadLengthFromInlineCallFrame): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread): (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue): (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength): (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee): (JSC::FTL::DFG::LowerDFGToB3::callPreflight): (JSC::FTL::DFG::LowerDFGToB3::appendOSRExitDescriptor): (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): (JSC::FTL::DFG::LowerDFGToB3::addressFor): (JSC::FTL::DFG::LowerDFGToB3::payloadFor): (JSC::FTL::DFG::LowerDFGToB3::tagFor): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor): * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * ftl/FTLOutput.cpp: (JSC::FTL::Output::select): * ftl/FTLOutput.h: * ftl/FTLSelectPredictability.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp. * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * generator/Checkpoints.rb: Added. * generator/Opcode.rb: * generator/Section.rb: * heap/Heap.cpp: (JSC::Heap::gatherScratchBufferRoots): * interpreter/CallFrame.cpp: (JSC::CallFrame::callSiteAsRawBits const): (JSC::CallFrame::unsafeCallSiteAsRawBits const): (JSC::CallFrame::callSiteIndex const): (JSC::CallFrame::unsafeCallSiteIndex const): (JSC::CallFrame::setCurrentVPC): (JSC::CallFrame::bytecodeIndex): (JSC::CallFrame::codeOrigin): * interpreter/CallFrame.h: (JSC::CallSiteIndex::CallSiteIndex): (JSC::CallSiteIndex::operator bool const): (JSC::CallSiteIndex::operator== const): (JSC::CallSiteIndex::bits const): (JSC::CallSiteIndex::fromBits): (JSC::CallSiteIndex::bytecodeIndex const): (JSC::DisposableCallSiteIndex::DisposableCallSiteIndex): (JSC::CallFrame::callee const): (JSC::CallFrame::unsafeCallee const): (JSC::CallFrame::addressOfCodeBlock const): (JSC::CallFrame::argumentCountIncludingThis const): (JSC::CallFrame::offsetFor): (JSC::CallFrame::setArgumentCountIncludingThis): (JSC::CallFrame::setReturnPC): * interpreter/CallFrameInlines.h: (JSC::CallFrame::r): (JSC::CallFrame::uncheckedR): (JSC::CallFrame::guaranteedJSValueCallee const): (JSC::CallFrame::jsCallee const): (JSC::CallFrame::codeBlock const): (JSC::CallFrame::unsafeCodeBlock const): (JSC::CallFrame::setCallee): (JSC::CallFrame::setCodeBlock): * interpreter/CheckpointOSRExitSideState.h: Copied from Source/JavaScriptCore/dfg/DFGThunks.h. * interpreter/Interpreter.cpp: (JSC::eval): (JSC::sizeOfVarargs): (JSC::loadVarargs): (JSC::setupVarargsFrame): (JSC::UnwindFunctor::operator() const): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * interpreter/Interpreter.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readInlinedFrame): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr): (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32): (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64): (JSC::AssemblyHelpers::emitPutToCallFrameHeader): (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::addressFor): (JSC::AssemblyHelpers::tagFor): (JSC::AssemblyHelpers::payloadFor): (JSC::AssemblyHelpers::calleeFrameSlot): (JSC::AssemblyHelpers::calleeArgumentSlot): (JSC::AssemblyHelpers::calleeFrameTagSlot): (JSC::AssemblyHelpers::calleeFramePayloadSlot): (JSC::AssemblyHelpers::calleeFrameCallerFrame): (JSC::AssemblyHelpers::argumentCount): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::CallFrameShuffler): * jit/CallFrameShuffler.h: (JSC::CallFrameShuffler::setCalleeJSValueRegs): (JSC::CallFrameShuffler::assumeCalleeIsCell): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareAndJumpImpl): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsignedAndJumpImpl): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareUnsignedImpl): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_compareAndJumpSlowImpl): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emit_op_mod): (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitnot): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileOpCall): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITInlines.h: (JSC::JIT::isOperandConstantDouble): (JSC::JIT::getConstantOperand): (JSC::JIT::emitPutIntToCallFrameHeader): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResult): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::isOperandConstantChar): (JSC::JIT::getOperandConstantInt): (JSC::JIT::getOperandConstantDouble): (JSC::JIT::emitInitRegister): (JSC::JIT::emitLoadTag): (JSC::JIT::emitLoadPayload): (JSC::JIT::emitGet): (JSC::JIT::emitPutVirtualRegister): (JSC::JIT::emitLoad): (JSC::JIT::emitLoad2): (JSC::JIT::emitLoadDouble): (JSC::JIT::emitLoadInt32ToDouble): (JSC::JIT::emitStore): (JSC::JIT::emitStoreInt32): (JSC::JIT::emitStoreCell): (JSC::JIT::emitStoreBool): (JSC::JIT::emitStoreDouble): (JSC::JIT::emitJumpSlowCaseIfNotJSCell): (JSC::JIT::isOperandConstantInt): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitGetVirtualRegisters): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jundefined_or_null): (JSC::JIT::emit_op_jnundefined_or_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emit_op_throw): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_numeric): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_new_regexp): (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_array): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_argument): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emitResolveClosure): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emitLoadWithStructureCheck): (JSC::JIT::emitGetClosureVar): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emitPutGlobalVariable): (JSC::JIT::emitPutGlobalVariableIndirect): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emitWriteBarrier): (JSC::JIT::emit_op_get_internal_field): (JSC::JIT::emit_op_put_internal_field): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::emitLoadJSCell): (JSC::JSInterfaceJIT::emitJumpIfNotJSCell): (JSC::JSInterfaceJIT::emitLoadInt32): (JSC::JSInterfaceJIT::emitLoadDouble): (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr): (JSC::JSInterfaceJIT::emitPutToCallFrameHeader): (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadDoubleArgument): (JSC::SpecializedThunkJIT::loadCellArgument): (JSC::SpecializedThunkJIT::loadInt32Argument): * jit/ThunkGenerators.cpp: (JSC::absThunkGenerator): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::getNonConstantOperand): (JSC::LLInt::getOperand): (JSC::LLInt::genericCall): (JSC::LLInt::varargsSetup): (JSC::LLInt::commonCallEval): (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::handleVarargsCheckpoint): (JSC::LLInt::dispatchToNextInstruction): (JSC::LLInt::slow_path_checkpoint_osr_exit_from_inlined_call): (JSC::LLInt::slow_path_checkpoint_osr_exit): (JSC::LLInt::llint_throw_stack_overflow_error): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::fill): * runtime/CachedTypes.cpp: (JSC::CachedCodeBlock::hasCheckpoints const): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::CachedCodeBlock::encode): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/ConstructData.cpp: (JSC::construct): * runtime/ConstructData.h: * runtime/DirectArguments.cpp: (JSC::DirectArguments::copyToArguments): * runtime/DirectArguments.h: * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::copyToArguments): * runtime/JSArray.cpp: (JSC::JSArray::copyToArguments): * runtime/JSArray.h: * runtime/JSImmutableButterfly.cpp: (JSC::JSImmutableButterfly::copyToArguments): * runtime/JSImmutableButterfly.h: * runtime/JSLock.cpp: (JSC::JSLock::willReleaseLock): * runtime/ModuleProgramExecutable.cpp: (JSC::ModuleProgramExecutable::create): * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/ScopedArguments.cpp: (JSC::ScopedArguments::copyToArguments): * runtime/ScopedArguments.h: * runtime/VM.cpp: (JSC::VM::scanSideState const): (JSC::VM::addCheckpointOSRSideState): (JSC::VM::findCheckpointOSRSideState): * runtime/VM.h: (JSC::VM::hasCheckpointOSRSideState const): * tools/VMInspector.cpp: (JSC::VMInspector::dumpRegisters): * wasm/WasmFunctionCodeBlock.h: (JSC::Wasm::FunctionCodeBlock::getConstant const): (JSC::Wasm::FunctionCodeBlock::getConstantType const): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::setUsesCheckpoints const): * wasm/WasmOperations.cpp: (JSC::Wasm::operationWasmToJSException): * wasm/WasmSlowPaths.cpp: 2020-01-16 Keith Miller Revert 254725 since it breaks tests https://bugs.webkit.org/show_bug.cgi?id=206391 Unreviewed, revert. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2020-01-16 Tadeu Zagallo Object allocation sinking is missing PutHint for sunken allocations https://bugs.webkit.org/show_bug.cgi?id=203799 Reviewed by Saam Barati. Consider the following graph: Block #0: 1: PhantomCreateActivation() 2: PhantomNewFunction() PutHint(@2, @1, FunctionActivationPLoc) Branch(#1, #2) Block #1: 3: MaterializeCreateActivation() PutHint(@2, @3, FunctionActivationPLoc) Upsilon(@3, ^5) Jump(#3) Block #2: 4: MaterializeCreateActivation() PutHint(@2, @4, FunctionActivationPLoc) Upsilon(@4, ^5) Jump(#3) Block #3: 5: Phi() ExitOK() On Block #3, we need to emit a PutHint after the Phi, since we might exit after it. However, object allocation sinking skipped this Phi because it was checking whether the base of the location that caused us to create this Phi (@2) was live, but it's dead in the graph (there are no pointers to it). The issue is that, even though there are no pointers to the base, the location `PromotedHeapLocation(@2, FunctionActivationPLoc)` is still live, so we should PutHint to it. We fix it by checking for liveness of the location rather than its base. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2020-01-16 Robin Morisset Try to simplify the template deduction used by callOperation in DFGSpeculativeJIT https://bugs.webkit.org/show_bug.cgi?id=206329 Reviewed by Keith Miller. The change is very simple: stop using NoResultTag in callOperation, since it is redundant with !FunctionTraits::hasResult * dfg/DFGSlowPathGenerator.h: (JSC::DFG::CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutAccessorById): (JSC::DFG::SpeculativeJIT::compilePutGetterSetterById): (JSC::DFG::SpeculativeJIT::compilePutDynamicVar): (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal): (JSC::DFG::SpeculativeJIT::compileDefineDataProperty): (JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty): (JSC::DFG::SpeculativeJIT::compilePutByIdWithThis): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2020-01-16 Robin Morisset Teach the bytecode that arithmetic operations can return bigints https://bugs.webkit.org/show_bug.cgi?id=205416 Reviewed by Yusuke Suzuki. Add already has the correct ResultType, but previously Sub/Mult/Div/Mod/Pow/Negate were always claimed to return Number, and when BigInt is enabled they can also return BigInt. UnaryPlus is left unchanged as it is invalid on a BigInt (to keep asm.js working as intended). * parser/NodeConstructors.h: (JSC::NegateNode::NegateNode): (JSC::PowNode::PowNode): (JSC::MultNode::MultNode): (JSC::DivNode::DivNode): (JSC::ModNode::ModNode): (JSC::SubNode::SubNode): * parser/ResultType.h: (JSC::ResultType::bigIntOrNumberType): Added. (JSC::ResultType::forNonAddArith): (JSC::ResultType::forUnaryArith): 2020-01-16 Robin Morisset Use dataLogIf more regularly https://bugs.webkit.org/show_bug.cgi?id=206332 Reviewed by Keith Miller. There is lots of code that reads if (Options::foobar()) dataLogLn("...") There are a couple of benefits to replacing those by dataLogLnIf(Options::foobar(), "..."): - Readability, by reducing the number of lines taken by logging - Less lines appearing as not-taken in test coverage wrongly (wrongly because we probably don't care for the coverage of logging code) - possibly a tiny perf benefit since dataLogIf correctly uses UNLIKELY. This patch is a fairly trivial refactoring where I looked for that pattern and replaced it everywhere it appeared in JSC. * bytecode/BytecodeGeneratorification.cpp: (JSC::performGeneratorification): * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis): * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::visitWeak): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::noticeIncomingCall): (JSC::CodeBlock::optimizationThresholdScalingFactor): (JSC::CodeBlock::optimizeNextInvocation): (JSC::CodeBlock::dontOptimizeAnytimeSoon): (JSC::CodeBlock::optimizeAfterWarmUp): (JSC::CodeBlock::optimizeAfterLongWarmUp): (JSC::CodeBlock::optimizeSoon): (JSC::CodeBlock::forceOptimizationSlowPathConcurrently): (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): (JSC::CodeBlock::shouldOptimizeNow): * bytecode/DFGExitProfile.cpp: (JSC::DFG::ExitProfile::add): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseCodeBlock): * dfg/DFGCFAPhase.cpp: * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::optimizeNextInvocation): (JSC::DFG::JITCode::dontOptimizeAnytimeSoon): (JSC::DFG::JITCode::optimizeAfterWarmUp): (JSC::DFG::JITCode::optimizeSoon): (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently): (JSC::DFG::JITCode::setOSREntryBlock): * dfg/DFGJumpReplacement.cpp: (JSC::DFG::JumpReplacement::fire): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileExit): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGOperations.cpp: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGToFTLDeferredCompilationCallback.cpp: (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously): (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete): * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp: (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously): (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete): * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::completeAllReadyPlansForVM): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): (JSC::Heap::sweepSynchronously): (JSC::Heap::collectNow): (JSC::Heap::runBeginPhase): (JSC::Heap::runFixpointPhase): (JSC::Heap::runReloopPhase): (JSC::Heap::runEndPhase): (JSC::Heap::finalize): (JSC::Heap::willStartCollection): (JSC::Heap::updateAllocationLimits): (JSC::Heap::notifyIsSafeToCollect): * heap/MarkStackMergingConstraint.cpp: (JSC::MarkStackMergingConstraint::prepareToExecuteImpl): * heap/MarkedSpace.cpp: * heap/MarkingConstraint.cpp: (JSC::MarkingConstraint::prepareToExecute): * heap/MarkingConstraintSet.cpp: (JSC::MarkingConstraintSet::executeConvergence): (JSC::MarkingConstraintSet::executeConvergenceImpl): (JSC::MarkingConstraintSet::executeAll): * heap/MarkingConstraintSolver.cpp: (JSC::MarkingConstraintSolver::execute): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::appendToMarkStack): (JSC::SlotVisitor::visitChildren): (JSC::SlotVisitor::didRace): * heap/StochasticSpaceTimeMutatorScheduler.cpp: (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection): (JSC::StochasticSpaceTimeMutatorScheduler::didExecuteConstraints): * jit/JIT.cpp: (JSC::JIT::link): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITOperations.cpp: * jit/JITToDFGDeferredCompilationCallback.cpp: (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously): (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete): * jit/JITWorklist.cpp: (JSC::JITWorklist::Plan::finalize): * jit/PolymorphicCallStubRoutine.cpp: (JSC::PolymorphicCallNode::unlink): * jit/Repatch.cpp: (JSC::unlinkFor): (JSC::linkVirtualFor): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * parser/ModuleAnalyzer.cpp: (JSC::ModuleAnalyzer::analyze): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::importModule): (JSC::JSModuleLoader::resolveSync): (JSC::JSModuleLoader::fetch): (JSC::JSModuleLoader::evaluate): (JSC::moduleLoaderModuleDeclarationInstantiation): * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::installCode): * runtime/VM.cpp: (JSC::VM::throwException): * tools/CompilerTimingScope.cpp: (JSC::CompilerTimingScope::CompilerTimingScope): (JSC::CompilerTimingScope::~CompilerTimingScope): * wasm/WasmMemory.cpp: * wasm/js/JSWebAssembly.cpp: (JSC::resolve): * yarr/YarrJIT.cpp: (JSC::Yarr::jitCompile): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPattern::compile): 2020-01-16 Robin Morisset Reduce the code generated by DFGSlowPathGenerator.h https://bugs.webkit.org/show_bug.cgi?id=206330 Reviewed by Mark Lam. The FunctionType parameter is only needed by CallResultAndArgumentsSlowPathGenerator, not by its base class CallSlowPathGenerator. Moving it allows saving about 200kB from JavaScriptCore (in Release mode), by reducing the number of instantiations of the methods of CallSlowPathGenerator. * dfg/DFGSlowPathGenerator.h: (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator): (JSC::DFG::CallResultAndArgumentsSlowPathGenerator::CallResultAndArgumentsSlowPathGenerator): 2020-01-16 Don Olmstead Non-unified build fixes mid January 2020 edition https://bugs.webkit.org/show_bug.cgi?id=206363 Unreviewed build fix. * interpreter/StackVisitor.cpp: 2020-01-16 Jonathan Bedard Pass JSToken by const reference https://bugs.webkit.org/show_bug.cgi?id=206321 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser::createBindingPattern): Pass JSToken by const reference. * parser/Parser.h: Ditto. 2020-01-16 Mark Lam operationToObject() should check for a null errorMessage. https://bugs.webkit.org/show_bug.cgi?id=206339 Reviewed by Yusuke Suzuki. r224280 introduced operationToObject() with an option to specify a custom error message. r254252 added a scenario where the passed in error message is null but did not update operationToObject() to allow for this. This patch adds the missing null check. * dfg/DFGOperations.cpp: 2020-01-16 Per Arne Vollan [Win] Fix AppleWin build https://bugs.webkit.org/show_bug.cgi?id=206299 Reviewed by Brent Fulgham. Include required target. Build internal builds with VS2019. * CMakeLists.txt: * JavaScriptCore.vcxproj/JavaScriptCore.proj: 2020-01-16 Caio Lima [JSC] 32-bit platforms should use a PC base register https://bugs.webkit.org/show_bug.cgi?id=203563 Reviewed by Keith Miller. We are moving 32-bits LLInt implementation to follow the model useb by 64-bits architectures. It means that we now use PC and PB registers to represent current Instruction. This patch will reduce the changes we have from those architectures and mainly allow the usage of new version of BytecodeIndex::m_packedBits. This also allow us remove divergences on CallSiteIndex. The change required the inclusion of a new callee-save register on ARMv7 (r10), MIPS($s1) and CLOOP. Further changes necessary for Baseline and DFG will come in a following patch. * assembler/MIPSRegisters.h: * interpreter/CallFrame.cpp: * jit/GPRInfo.h: (JSC::GPRInfo::toRegister): (JSC::GPRInfo::toIndex): * jit/RegisterSet.cpp: (JSC::RegisterSet::vmCalleeSaveRegisters): (JSC::RegisterSet::llintBaselineCalleeSaveRegisters): * llint/LLIntData.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm.rb: * offlineasm/mips.rb: 2020-01-15 Caitlin Potter [JSC] Add support for public class fields https://bugs.webkit.org/show_bug.cgi?id=174212 Reviewed by Yusuke Suzuki. Implements the instance class fields proposal (https://tc39.es/proposal-class-fields/), minus support for private fields (split into a separate patch). In summary, class fields are initialized by a synthetic JSFunction. In its unlinked state, the UnlinkedFunctionExecutable for the function includes an ordered list of JSTokenLocations pointing to the start of each class field in the class. Each of these fields are parsed and included as DefineFieldNodes, which implement the appropriate DefineField behaviour in the proposal. This synthetic function is only created, and only loaded, if there are class fields present. The decision to use a synthetic function was for simplicity. There are a number of factors which make inlining the initialization complicated, though we may opt to do this in the future. For reference, the complexities are: instance fields and constructor in different currently in different parsing arenas, distinct scopes between the 2 which require work to manage, and complexity in doing to this work for child classes, where the location of initialization can depend, and in some cases occur more than once. Computed property fields require a new bytecode, op_to_property_key, as an implementation detail. It is necessary in the proposal to convert computed properties to property keys during class evaluation, rather than during field initialization. Additionally, we allocate the class lexical scope when computed class fields are used (previously, only when there was a class name), as a location to keep the computed property keys. They can be loaded from the scope via indexed keys. To illustrate computed field names in action, consider the following pseudocode: 1) fieldName = emitNode({expr}) 2) fieldName = emitToPropertyKey(fieldName) 3) classScope[numComputedNames++] = fieldName 1) fieldName = emitGetFromScope(classScope, computedFieldNameIndex++) 2) value = emitNode({initializer}) 3) instance[fieldName] = value The feature is currently hidden behind the feature flag JSC::Options::useClassFields. 2020-01-15 Adrian Perez de Castro Offlineasm warnings with newer Ruby versions https://bugs.webkit.org/show_bug.cgi?id=206233 Reviewed by Yusuke Suzuki. Avoid a warning about using Object#=~ on Annotation instances, which has been deprecated in Ruby 2.7. * offlineasm/parser.rb: Swap checks to prevent applying the =~ operator to Annotation instances, which do not define it. 2020-01-15 Keith Miller Revert bytecode checkpoints since it breaks watch https://bugs.webkit.org/show_bug.cgi?id=206301 Unreviewed, revert. 2020-01-15 Alexey Shvayka Object.preventExtensions should throw if not successful https://bugs.webkit.org/show_bug.cgi?id=206131 Reviewed by Ross Kirsling. With this change, Object.preventExtensions throws TypeError if [[PreventExtensions]] returns `false`. This is possible if Object.preventExtensions is called on a Proxy object. (step 3 of https://tc39.es/ecma262/#sec-object.preventextensions) * runtime/ObjectConstructor.cpp: (JSC::objectConstructorPreventExtensions): 2020-01-15 Jonathan Bedard webkitpy: Remove self assignments https://bugs.webkit.org/show_bug.cgi?id=206294 Reviewed by Aakash Jain. * inspector/scripts/codegen/generator.py: (Generator.js_name_for_parameter_type): 2020-01-14 Commit Queue Unreviewed, rolling out r254480, r254496, and r254517. https://bugs.webkit.org/show_bug.cgi?id=206278 "It regressed JetStream2 and Speedometer2" (Requested by saamyjoon on #webkit). Reverted changesets: "Throw away baseline code if there is an optimized replacement" https://bugs.webkit.org/show_bug.cgi?id=202503 https://trac.webkit.org/changeset/254480 "Unreviewed. Change useLLInt=0 to forceBaseline=1" https://trac.webkit.org/changeset/254496 "Add an option that enables/disables throwing away baseline JIT code" https://bugs.webkit.org/show_bug.cgi?id=206244 https://trac.webkit.org/changeset/254517 2020-01-14 Keith Miller Fix scanSideState assertion https://bugs.webkit.org/show_bug.cgi?id=206257 Reviewed by Yusuke Suzuki. * runtime/VM.cpp: (JSC::VM::scanSideState const): 2020-01-14 Devin Rousso Web Inspector: crash in DumpRenderTree at com.apple.JavaScriptCore: WTF::RefCountedBase::hasOneRef const https://bugs.webkit.org/show_bug.cgi?id=206191 Reviewed by Joseph Pecoraro. * debugger/Debugger.cpp: (JSC::Debugger::attach): (GatherSourceProviders::GatherSourceProviders): Deleted. (GatherSourceProviders::operator()): Deleted. Use `RefPtr` instead of `SourceProvider*` in case the `FunctionExecutable` is destroyed after the `SourceProvider*` is saved, which would destroy the `SourceProvider` as well. 2020-01-14 Saam Barati Add an option that enables/disables throwing away baseline JIT code https://bugs.webkit.org/show_bug.cgi?id=206244 Reviewed by Robin Morisset. This option is now set to false as I investigate a perf regression with the original patch. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeUnconditionally): * runtime/OptionsList.h: 2020-01-13 Darin Adler Use even more "shortest form" formatting, and less "fixed precision" and "fixed width" https://bugs.webkit.org/show_bug.cgi?id=198918 Reviewed by Sam Weinig. * API/tests/ExecutionTimeLimitTest.cpp: (testExecutionTimeLimit): Rewrote the string creation code to use makeString instead of StringBuilder and no longer use any fixed precision. * runtime/Options.cpp: (JSC::OptionReader::Option::dump const): Dump doubles with shortest form instead of fixed precision. 2020-01-14 David Kilzer Enable -Wconditional-uninitialized in bmalloc, WTF, JavaScriptCore Reviewed by Mark Lam. Initialize stack variables to fix warnings. * Configurations/Base.xcconfig: (WARNING_CFLAGS): Add -Wconditional-uninitialized. * b3/B3LowerToAir.cpp: (LowerToAir::appendCAS): * b3/testb3_4.cpp: (testLoadAddrShift): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureOrEmpty): Move declaration of `notEmpty` into if block since it's not used outside that scope. (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter): * ftl/FTLThunks.cpp: (JSC::FTL::registerClobberCheck): * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::webAssemblyTableProtoFuncSet): variables. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::parseBody): 2020-01-13 Fujii Hironori Unreviewed sort-Xcode-project-file * JavaScriptCore.xcodeproj/project.pbxproj: 2020-01-13 Keith Miller scanSideState scans too much side state https://bugs.webkit.org/show_bug.cgi?id=206166 Reviewed by Tadeu Zagallo. The old code would would scan tmps + sizeof(tmps) but sizeof(tmps) is not the length of the array. instead we should scan tmps + maxNumCheckpointTmps. * interpreter/CheckpointOSRExitSideState.h: * runtime/VM.cpp: (JSC::VM::scanSideState const): 2020-01-13 Saam Barati Throw away baseline code if there is an optimized replacement https://bugs.webkit.org/show_bug.cgi?id=202503 Reviewed by Yusuke Suzuki. This patch's goal is to help us save JIT executable memory by throwing away baseline code when it has an optimized replacement. To make it easy to reason about, we do this when finalizing a GC, and when the CodeBlock is not on the stack. When we do this, we throw away all JIT data and unlink all incoming calls. This patch also paves the way for the LOL tier by making it so we always exit to the LLInt. This allows the code in CodeBlock finalization to not have to consider whether or not an an OSR exit is wired to baseline JIT code, since all exits are now to the LLInt. Because of this, this patch removes the forceOSRExitToLLInt option. Also, this patch renames the useLLInt option to forceBaseline and inverts its meaning. Options::forceBaseline=true implies that code will start off executing in the baseline JIT instead of the LLInt. However, it won't prevent us from emitting an OSR exit which jumps to LLInt code. * API/tests/ExecutionTimeLimitTest.cpp: (testExecutionTimeLimit): * API/tests/PingPongStackOverflowTest.cpp: (testPingPongStackOverflow): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::resetJITData): (JSC::CodeBlock::optimizedReplacement): (JSC::CodeBlock::hasOptimizedReplacement): (JSC::CodeBlock::tallyFrequentExitSites): (JSC::CodeBlock::findStubInfo): Deleted. (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex): Deleted. * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::isCurrentlyExecuting): * heap/CodeBlockSet.h: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): (JSC::Heap::runEndPhase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::dispatchToNextInstruction): * runtime/Options.cpp: (JSC::recomputeDependentOptions): (JSC::Options::initialize): (JSC::Options::ensureOptionsAreCoherent): * runtime/OptionsList.h: * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::prepareForExecutionImpl): 2020-01-13 Mark Lam Replace uses of Box with a new CacheableIdentifier class. https://bugs.webkit.org/show_bug.cgi?id=205544 Reviewed by Saam Barati. The introduction of the use of Box was to get around having to ref/deref the underlying UniqedStringImpl in Identifiers from the compiler and GC threads. However, it proves to be difficult to control when these Boxs get destructed, and requires that we find all the places in the compier and GC threads where this can happen, and apply keep alive tactics there to defer destruction of the Box to the mutator thread. This patch fixes this by replacing uses of Box with CacheableIdentifier, which is effectively a tagged union of a JSCell* or a UniquedStringImpl*. The JSCell*, in this case, can be either a Symbol* or a JSString* that is backed by an atom string. The VM runtime ensures that we'll never try to cache an identifier from a JSCell that is not one of these. This CacheableIdentifier can be destructed from the compiler or GC thread. Since it doesn't hold a ref of the underlying UniquedStringImpl, it won't try to deref it on destruction. Instead, we'll need to visit CacheableIdentifiers during GC scans to keep the JSCell in it alive, and that JSCell will, in turn, keep the underlying UniquedStringImpl alive. This patch also does the following: 1. Add a visitAggregate() method to StructureStubInfo, PolymorphicAccess, and AccessCase to visit the CacheableIdentifier's JSCell identifier. This visitAggregate() is called from CodeBlock::stronglyVisitStrongReferences(). When we write barrier a CodeBlock, it guarantees that its visitAggregate() methods is called. However, it does not guarantee that its propagateTransitions() method will be called. Since the CacheableIdentifier's reference to a cell should be a strong reference, visiting it via a StructureStubInfo::visitAggregate() method is the right thing to do. See https://bugs.webkit.org/show_bug.cgi?id=205544#c7 for an example of why propagateTransitions() doesn't always do the job. StructureStubInfo::visitWeakReferences() is also inappropriate for this because it is only called after all marking is done. It is also not meant to keep cells alive but merely for clearing weak references to dead cells. 2. Also add to visitAggregate() for ModuleNamespaceData's m_identifier in GetByStatus::markIfCheap(). 3. Remove previously applied keep alive tactics to work around Box destruction. This also retores the allowance to destruct DFG::Plans on a compiler thread. 4. Added a JSString:getValueImpl() helper. 5. Added a write barrier in DFG and FTL JITFinalizer's finalizeCommon() to ensure that frozen values are scanned by the GC. During compilation, the frozen values were previously protected by the Plan. After finalization, they should be protected by the CodeBlock. Hence, we should barrier the CodeBlock since the last GC scan of the CodeBlock may have happened before the frozen values were registered with the CodeBlock. GC considerations: ================== The following also addresses Yusuke's concerns in https://bugs.webkit.org/show_bug.cgi?id=205544#c10. CacheableIdentifier is only stored as fields in 4 classes/structs: 1. AccessCase::m_identifier 2. GetByIdVariant::m_identifier 3. ModuleNamespaceData::m_identifier 4. StructureStubInfo::m_getByIdSelfIdentifier AccessCase::m_identifier ======================== While the access case is being created and added in tryCacheGetBy(), the CacheableIdentifier is still on the stack and protected from the GC. At the bottom of tryCacheGetBy(), StructureStubInfo::addAccessCase() is called to add the access case. StructureStubInfo::addAccessCase() will barrier the owner CodeBlock at its end, and CodeBlock::stronglyVisitStrongReferences() will visit the StructureStubInfo, which in turn visits the AccessCase. StructureStubInfo::visitAggregate() has been added for this purpose. GetByIdVariant::m_identifier ============================ GetByIdVariant is only stored in GetByStatus. Both GetByIdVariant and GetByStatus are only created and handled in the DFG/FTL compiler threads. While the compiler thread is working with them, they are safe from the GC because the GC won't collect objects until the compiler thread is at a SafePoint. At compiler SafePoints, any GetByStatus that needs to be persisted is stored in DFG::Plan::m_recordedStatuses. The Plan will visit the m_recordedStatuses in Plan::checkLivenessAndVisitChildren(). At the end of compilation, Plan::m_recordedStatuses is transferred over to the owner CodeBlock's DFG::CommonData in Plan::finalizeWithoutNotifyingCallback(). Plan::finalizeWithoutNotifyingCallback() will also barrier the owner CodeBlock at its end. Thereafter, CodeBlock::stronglyVisitStrongReferences() will visit the recordedStatuses. ModuleNamespaceData::m_identifier ================================= ModuleNamespaceData is only stored in a GetByStatus, and is therefore protected similarly as the GetByIdVariant::m_identifier case above. StructureStubInfo::m_getByIdSelfIdentifier ========================================== StructureStubInfo::initGetByIdSelf() is called from inside tryCacheGetBy(). StructureStubInfo::initGetByIdSelf() will barrier the owner CodeBlock. The CacheableIdentifier here is protected in the same way as the AccessCase::m_identifier case above. DesiredIdentifiers ================== The compiler thread may also stash a CacheableIdentifier's uid in its DesiredIdentifiers. Normally, the identifiers stashed in DesiredIdentifiers are from identifiers that the CodeBlock already knows abut and manages (e.g. from GetByIds). For uids from a cell-based CacheableIdentifier variable is passed to a GetByVal, we need kep the cell alive in order to keep the uid alive. This is achieved by freezing the cell with freezeStrong() in the op_get_by_val case in the DFG BytecodeParser. Reseting a StructureStubInfo while its IC code is still executing on the stack ============================================================================== The concern is that IC code may call slow path / getter functions that may in turn: 1. reset the IC, and 2. run the GC. This can be a problem if: 1. there is a scenario where we return from the slow path / getter function and run IC code that uses the cell / uid from the CacheableIdentifier. This is because the StructureStubInfo is what visits the that cell, which in turn its uid alive. Once the StructureStubInfo is reset, it will no longer be associated with any AccessCase or the m_getByIdSelfIdentifier. As such they will not be visited, and the CacheableIdentifier may be collected by the GC. In practice, the generated IC code never uses the cell / uid after it calls any slow path / getter function. I've verified this by auditing the code generation in InlineAccess::generateSelfInAccess() and PolymorphicAccess::regenerate(). Hence, there's no issue with using a collected cell / uid. 2. there is a scenario where a slow path / getter function makes use of the cell / uid from the CacheableIdentifier but does not protect it. The only 2 slow path functions: operationGetByValGeneric() operationGetByValOptimize() operationGetByValGeneric() does not use any CacheableIdentifier from the StructureStubInfo. operationGetByValOptimize() modifies the StructureStubInfo in tryCacheGetBy() under the protection of a GCSafeConcurrentJSLocker, and can reset the StructureStubInfo. However, it does not use any CacheableIdentifier after that. Hence, there's also no GC issue here. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::AccessCase): (JSC::AccessCase::create): (JSC::AccessCase::fromStructureStubInfo): (JSC::AccessCase::commit): (JSC::AccessCase::canReplace const): (JSC::AccessCase::dump const): (JSC::AccessCase::visitAggregate const): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): * bytecode/AccessCase.h: (JSC::AccessCase::uid const): (JSC::AccessCase::identifier const): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::stronglyVisitStrongReferences): * bytecode/GetByIdVariant.cpp: (JSC::GetByIdVariant::GetByIdVariant): (JSC::GetByIdVariant::attemptToMerge): (JSC::GetByIdVariant::visitAggregate): (JSC::GetByIdVariant::dumpInContext const): * bytecode/GetByIdVariant.h: (JSC::GetByIdVariant::identifier const): (JSC::GetByIdVariant::overlaps): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeFromLLInt): (JSC::GetByStatus::computeFor): (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::GetByStatus::visitAggregate): (JSC::GetByStatus::singleIdentifier const): * bytecode/GetByStatus.h: * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::GetterSetterAccessCase): (JSC::GetterSetterAccessCase::create): * bytecode/GetterSetterAccessCase.h: * bytecode/InstanceOfAccessCase.cpp: (JSC::InstanceOfAccessCase::InstanceOfAccessCase): * bytecode/IntrinsicGetterAccessCase.cpp: (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase): (JSC::IntrinsicGetterAccessCase::create): * bytecode/IntrinsicGetterAccessCase.h: * bytecode/ModuleNamespaceAccessCase.cpp: (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase): (JSC::ModuleNamespaceAccessCase::create): * bytecode/ModuleNamespaceAccessCase.h: * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::visitAggregate): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: * bytecode/ProxyableAccessCase.cpp: (JSC::ProxyableAccessCase::ProxyableAccessCase): (JSC::ProxyableAccessCase::create): * bytecode/ProxyableAccessCase.h: * bytecode/RecordedStatuses.cpp: (JSC::RecordedStatuses::visitAggregate): * bytecode/RecordedStatuses.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::visitAggregate): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::getByIdSelfIdentifier): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDesiredIdentifiers.cpp: (JSC::DFG::DesiredIdentifiers::ensure): (JSC::DFG::DesiredIdentifiers::at const): (JSC::DFG::DesiredIdentifiers::reallyAdd): (JSC::DFG::DesiredIdentifiers::processCodeBlockIdentifiersIfNeeded): Deleted. * dfg/DFGDesiredIdentifiers.h: * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalizeCommon): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::~Plan): (JSC::DFG::Plan::checkLivenessAndVisitChildren): (JSC::DFG::Plan::cancel): * dfg/DFGPlan.h: (JSC::DFG::Plan::keepAliveIdentifier): Deleted. * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::removeAllReadyPlansForVM): (JSC::DFG::Worklist::removeDeadPlans): (JSC::DFG::Worklist::removeNonCompilingPlansForVM): (JSC::DFG::Worklist::deleteCancelledPlansForVM): Deleted. * dfg/DFGWorklist.h: * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeCommon): * jit/JITOperations.cpp: * jit/Repatch.cpp: (JSC::tryCacheGetBy): (JSC::repatchGetBy): (JSC::tryCacheArrayGetByVal): (JSC::tryCacheInstanceOf): * jit/Repatch.h: * runtime/CacheableIdentifier.cpp: Added. (JSC::CacheableIdentifier::dump const): * runtime/CacheableIdentifier.h: Added. (JSC::CacheableIdentifier::CacheableIdentifier): (JSC::CacheableIdentifier::isUid const): (JSC::CacheableIdentifier::isCell const): (JSC::CacheableIdentifier::isSymbol const): (JSC::CacheableIdentifier::operator bool const): * runtime/CacheableIdentifierInlines.h: Added. (JSC::CacheableIdentifier::CacheableIdentifier): (JSC::CacheableIdentifier::cell const): (JSC::CacheableIdentifier::uid const): (JSC::CacheableIdentifier::isCacheableIdentifierCell): (JSC::CacheableIdentifier::isSymbolCell const): (JSC::CacheableIdentifier::isStringCell const): (JSC::CacheableIdentifier::setCellBits): (JSC::CacheableIdentifier::setUidBits): (JSC::CacheableIdentifier::visitAggregate const): (JSC::CacheableIdentifier::operator== const): (JSC::CacheableIdentifier::operator!= const): * runtime/ExceptionHelpers.cpp: (JSC::functionCallBase): * runtime/JSString.h: (JSC::JSString::getValueImpl const): * runtime/VM.cpp: (JSC::VM::ensureWatchpointSetForImpureProperty): (JSC::VM::addImpureProperty): (JSC::VM::registerWatchpointForImpureProperty): Deleted. * runtime/VM.h: 2020-01-13 Yusuke Suzuki [JSC] Put JSProxy in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=206187 Reviewed by Mark Lam. 1. Put JSProxy in IsoSubspace. 2. Make JSProxy non-destructible since derived class JSWindowProxy is having its own IsoSubspace with destructibility. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::resetPrototype): (JSC::JSGlobalObject::finishCreation): * runtime/JSNonDestructibleProxy.cpp: Removed. * runtime/JSNonDestructibleProxy.h: Removed. * runtime/JSProxy.h: (JSC::JSProxy::subspaceFor): * runtime/JSStringIterator.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2020-01-11 Keith Miller CheckNeutered needs to claim it reads JSType in clobberize. https://bugs.webkit.org/show_bug.cgi?id=206136 Reviewed by Yusuke Suzuki. CheckNeutered needs to read JSType otherwise it can get hoisted past the TypedArray check guarding it. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2020-01-12 Yusuke Suzuki [JSC] Use internal object field mechanism to implement JSStringIterator https://bugs.webkit.org/show_bug.cgi?id=206144 Reviewed by Ross Kirsling. This patch uses internal object field mechanism to implement JSStringIterator, and we also put JSStringIterator into IsoSubspace. * builtins/BuiltinNames.h: * builtins/StringIteratorPrototype.js: (next): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitIsStringIterator): * bytecompiler/NodesCodegen.cpp: (JSC::stringIteratorInternalFieldIndex): (JSC::BytecodeIntrinsicNode::emit_intrinsic_getStringIteratorInternalField): (JSC::BytecodeIntrinsicNode::emit_intrinsic_putStringIteratorInternalField): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::getInternalProperties): * runtime/JSCast.h: * runtime/JSStringIterator.cpp: (JSC::JSStringIterator::finishCreation): (JSC::JSStringIterator::clone): (JSC::JSStringIterator::visitChildren): (JSC::JSStringIterator::iteratedValue const): Deleted. * runtime/JSStringIterator.h: * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/StringPrototype.cpp: (JSC::stringProtoFuncIterator): * runtime/VM.cpp: * runtime/VM.h: 2020-01-12 Yusuke Suzuki [JSC] Remove IsDone from JSArrayIterator https://bugs.webkit.org/show_bug.cgi?id=206140 Reviewed by Keith Miller. We can store `-1` in Index field to represent whether the iterator is closed. While this patch does not change the allocation size of JSArrayIterator, this style can shrink the size of JSStringIterator when we implement it in the same style. We also rename iterationKindKeyValue to iterationKindEntries. * builtins/ArrayIteratorPrototype.js: (globalPrivate.arrayIteratorNextHelper): * builtins/MapIteratorPrototype.js: (globalPrivate.mapIteratorNext): * builtins/MapPrototype.js: (entries): * builtins/SetIteratorPrototype.js: (globalPrivate.setIteratorNext): * builtins/SetPrototype.js: (entries): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/NodesCodegen.cpp: (JSC::arrayIteratorInternalFieldIndex): * inspector/JSInjectedScriptHost.cpp: (Inspector::cloneArrayIteratorObject): * runtime/JSArrayIterator.cpp: (JSC::JSArrayIterator::finishCreation): * runtime/JSArrayIterator.h: 2020-01-12 Yusuke Suzuki [JSC] Consistently use "var" in builtin JS https://bugs.webkit.org/show_bug.cgi?id=206157 Reviewed by Mark Lam. let / const requires additional bytecode to make it Empty initialized for now. For builtin JS, we would like to keep it as efficient and compact as we can so we should use `var` consistently. * builtins/ArrayPrototype.js: (sort.stringComparator): (sort.compactSparse): (sort.compactSlow): (sort.compact): (sort.merge): (sort.mergeSort): (sort.bucketSort): (sort.comparatorSort): (sort.stringSort): (sort): (globalPrivate.concatSlowPath): (concat): * builtins/FunctionPrototype.js: (call): (overriddenName.string_appeared_here.symbolHasInstance): * builtins/GlobalOperations.js: (globalPrivate.copyDataProperties): (globalPrivate.copyDataPropertiesNoExclusions): * builtins/IteratorHelpers.js: (performIteration): * builtins/ModuleLoader.js: (async loadModule): (async loadAndEvaluateModule): (async requestImportModule): (dependencyKeysIfEvaluated): * builtins/ObjectConstructor.js: (fromEntries): * builtins/PromisePrototype.js: (finally): (valueThunk): (globalPrivate.getThenFinally): (thrower): (globalPrivate.getCatchFinally): (const.valueThunk): Deleted. (const.thrower): Deleted. * builtins/RegExpPrototype.js: (globalPrivate.advanceStringIndex): (globalPrivate.regExpExec): (globalPrivate.hasObservableSideEffectsForRegExpMatch): (globalPrivate.matchSlow): (overriddenName.string_appeared_here.match): (overriddenName.string_appeared_here.matchAll): (getSubstitution): (overriddenName.string_appeared_here.replace): (overriddenName.string_appeared_here.search): (globalPrivate.hasObservableSideEffectsForRegExpSplit): (overriddenName.string_appeared_here.split): (intrinsic.RegExpTestIntrinsic.test): * builtins/RegExpStringIteratorPrototype.js: (next): * builtins/StringPrototype.js: (match): (matchAll): (globalPrivate.hasObservableSideEffectsForStringReplace): (intrinsic.StringPrototypeReplaceIntrinsic.replace): (globalPrivate.createHTML): * builtins/TypedArrayConstructor.js: (of): (from): * builtins/TypedArrayPrototype.js: (globalPrivate.typedArraySpeciesConstructor): (globalPrivate.typedArrayClampArgumentToStartOrEnd): (fill): (find): (subarray): 2020-01-12 Yusuke Suzuki [WebCore] Reorganize JSType in WebCore to offer more bits to JSC https://bugs.webkit.org/show_bug.cgi?id=206141 Reviewed by Keith Miller. * runtime/JSType.h: 2020-01-11 Yusuke Suzuki Unreviewed, suppress warnings in GCC, part 2 https://bugs.webkit.org/show_bug.cgi?id=202832 * bytecode/ArithProfile.h: 2020-01-11 Yusuke Suzuki Unreviewed, suppress warnings in GCC https://bugs.webkit.org/show_bug.cgi?id=202832 * bytecode/ArithProfile.h: 2020-01-10 Yusuke Suzuki [JSC] Flush old tables in End phase https://bugs.webkit.org/show_bug.cgi?id=206120 Reviewed by Mark Lam. stopThePeriphery is stopping compiler threads and main thread (mutator), which means making m_worldIsStopped = true. It is not for stopping all heap threads including a concurrent marker. The concurrent collector can work while executing stopThePeriphery. This means that concurrent collectors can access to the old StructureIDTable while it is destroyed in stopThePeriphery. Destroying old StructureIDTable in GC End phase, this is appropriate phase that we can ensure no other threads (accessing to heap) are working including concurrent markers, mutator, and compiler threads. * heap/Heap.cpp: (JSC::Heap::runEndPhase): (JSC::Heap::stopThePeriphery): 2020-01-10 Caitlin Potter and Alexey Shvayka Object.keys should throw if called on module namespace object with uninitialized binding https://bugs.webkit.org/show_bug.cgi?id=205983 Reviewed by Yusuke Suzuki. If JSModuleNamespaceObject::getOwnPropertyNames method is called by Object.keys or for/in loop, it should invoke [[GetOwnProperty]] on every binding so a ReferenceError is thrown if the binding is uninitialized. Complete call stack of internal methods and abstract ops is in "info" meta of JSTests/test262/test/language/module-code/namespace/internals/object-keys-binding-uninit.js * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::getOwnPropertyNames): 2020-01-10 Saam Barati ObjectAllocationSinkingPhase doesn't model pointers to allocations in control flow properly https://bugs.webkit.org/show_bug.cgi?id=204738 Reviewed by Yusuke Suzuki. Allocation sinking phase conducts a points to analysis. It uses this information for programs like: ``` 1: NewObject 2: NewObject 3: PutByOffset(@2, @1, "x") 4: GetByOffset(@2, "x") ``` It solves the points to problem knowing @4 points to @1. It tracks this data in the LocalHeap data structure. This is used to track the heap across blocks, and it includes a merge function to handle control flow merges. However, this merge function would not always merge the pointer sets together. It sometimes would merge them together, since it had a fast path check inside merge, which would just copy the contents of the block to be merged with itself if it were this block's first time merging. This fast path happened to hide the bug in general case merge code. If we didn't take this fast path, we would just never transfer pointer sets from predecessor to successor. This could lead to all kinds of issues, including using the incorrect phantom node in IR instead of its materialized version. It could also lead to the phase not sinking objects it is capable of sinking. This patch makes it so that we merge together the pointer sets. We always add new pointers to the set. So in pointer A->B, if the set has yet to see A, we add it. If the set already contains pointer A->B, and we encounter a new pointer A->C, or if we encounter a merge without any A->* pointer, we mark the A pointer as top, marking it A->TOP. We do this to ensure that we fixpoint. We're guaranteed that m_pointers is monotonically increasing (module liveness pruning, which is a constant). And once something is TOP, it never becomes anything else. (Instead of marking a pointer top, we used to just remove it from the set, but this has issues, as it could lead to us ping-ponging in our fixpoint analysis, add, remove, add, remove, etc.) So the merge rules are: {A->B} merge {A->B} => {A->B} {A->B} merge {A->C} => {A->TOP} {A->B} merge {A->TOP} => {A->TOP} {A->B} merge {} => {A->TOP} Thanks to Samuel Groß of Google Project Zero for identifying this bug. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2020-01-10 Carlos Garcia Campos Unreviewed. Fix GTK and WPE API docs generation Add index for new symbols in 2.28. * API/glib/docs/jsc-glib-docs.sgml: 2020-01-10 Carlos Garcia Campos [GLIB] Add GLib specific API for JSC JSValueRef.h's JSValueMakeFromJSONString and JSValueCreateJSONString methods https://bugs.webkit.org/show_bug.cgi?id=205161 Reviewed by Adrian Perez de Castro. Add jsc_value_new_from_json() and jsc_value_to_json(). * API/glib/JSCValue.cpp: (jsc_value_new_from_json): (jsc_value_to_json): * API/glib/JSCValue.h: * API/glib/docs/jsc-glib-4.0-sections.txt: 2020-01-10 Adrian Perez de Castro Fix various non-unified build issues introduced since r253538 https://bugs.webkit.org/show_bug.cgi?id=205996 Reviewed by Youenn Fablet. * bytecode/ExecutableToCodeBlockEdge.cpp: Add missing inclusion of JSObjectInlines.h and StructureInlines.h * dfg/DFGVariableEvent.cpp: Add missing inclusion of OperandsInlines.h * runtime/NarrowingNumberPredictionFuzzerAgent.cpp: Add missing inclusion of CodeBlock.h * runtime/WideningNumberPredictionFuzzerAgent.cpp: Ditto. * wasm/WasmOperations.cpp: Add missing inclusion of ButterflyInlines.h 2020-01-09 Commit Queue Unreviewed, rolling out r254234. https://bugs.webkit.org/show_bug.cgi?id=206011 Broke production builds (Requested by ap on #webkit). Reverted changeset: "build-jsc should invoke make instead of calling xcodebuild directly" https://bugs.webkit.org/show_bug.cgi?id=205960 https://trac.webkit.org/changeset/254234 2020-01-08 Keith Miller [JSC] Introduce JSArrayIterator https://bugs.webkit.org/show_bug.cgi?id=204043 Reviewed by Yusuke Suzuki. This patch introduces JSArrayIterator that changes the iterator object from a JSFinalObject to an InternalFieldsObject. This makes accessing it much easier from C++ code and makes the iterator object smaller. It also means that the JS code for the next function is much simpler and can *almost* be inlined without shenanigans. As part of this patch the keys/values/entries functions have been converted to C++ with intrinsics since that's slightly more efficient in the LLInt/Baseline. Lastly, this patch also add a custom ISOSubspace for JSArrayIterator objects. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * builtins/ArrayIteratorPrototype.js: (next): (globalPrivate.arrayIteratorNextHelper): (globalPrivate.arrayIteratorValueNext): Deleted. (globalPrivate.arrayIteratorKeyNext): Deleted. (globalPrivate.arrayIteratorKeyValueNext): Deleted. * builtins/ArrayPrototype.js: (globalPrivate.ArrayIterator): Deleted. (values): Deleted. (keys): Deleted. (entries): Deleted. * builtins/TypedArrayPrototype.js: (values): Deleted. (keys): Deleted. (entries): Deleted. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitIsArrayIterator): * bytecompiler/NodesCodegen.cpp: (JSC::arrayIteratorInternalFieldIndex): (JSC::BytecodeIntrinsicNode::emit_intrinsic_getArrayIteratorInternalField): (JSC::BytecodeIntrinsicNode::emit_intrinsic_putArrayIteratorInternalField): (JSC::BytecodeIntrinsicNode::emit_intrinsic_isGenerator): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isAsyncGenerator): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isPromise): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isProxyObject): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isRegExpObject): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isObject): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isDerivedArray): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isMap): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isSet): Deleted. (JSC::BytecodeIntrinsicNode::emit_intrinsic_isUndefinedOrNull): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::convertToPhantomNewObject): (JSC::DFG::Node::convertToPhantomNewArrayIterator): (JSC::DFG::Node::convertToPhantomCreateActivation): (JSC::DFG::Node::hasStructure): (JSC::DFG::Node::hasObjectMaterializationData): (JSC::DFG::Node::isPhantomAllocation): * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGPromotedHeapLocation.cpp: (WTF::printInternal): * dfg/DFGPromotedHeapLocation.h: (JSC::DFG::PromotedLocationDescriptor::neededForMaterialization const): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckNeutered): (JSC::DFG::SpeculativeJIT::compileToObjectOrCallObjectConstructor): (JSC::DFG::SpeculativeJIT::compileNewInternalFieldObject): (JSC::DFG::SpeculativeJIT::compileNewArrayIterator): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileToObjectOrCallObjectConstructor): (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray): (JSC::FTL::DFG::LowerDFGToB3::compileCheckNeutered): (JSC::FTL::DFG::LowerDFGToB3::compileNewInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayIterator): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewInternalFieldObjectImpl): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewInternalFieldObject): * ftl/FTLOperations.cpp: (JSC::FTL::operationPopulateObjectInOSR): (JSC::FTL::operationMaterializeObjectInOSR): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::JSInjectedScriptHost::getInternalProperties): (Inspector::cloneArrayIteratorObject): (Inspector::JSInjectedScriptHost::iteratorEntries): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): (JSC::createArrayIteratorObject): (JSC::arrayProtoFuncValues): (JSC::arrayProtoFuncEntries): (JSC::arrayProtoFuncKeys): * runtime/CommonIdentifiers.h: * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/IterationKind.h: (): Deleted. * runtime/JSArrayIterator.cpp: Added. (JSC::JSArrayIterator::create): (JSC::JSArrayIterator::createWithInitialValues): (JSC::JSArrayIterator::createStructure): (JSC::JSArrayIterator::JSArrayIterator): (JSC::JSArrayIterator::finishCreation): (JSC::JSArrayIterator::visitChildren): * runtime/JSArrayIterator.h: Added. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::arrayIteratorPrototype const): (JSC::JSGlobalObject::arrayIteratorStructure const): * runtime/JSMapIterator.h: * runtime/JSSetIterator.h: * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/JSTypedArrayViewPrototype.cpp: (JSC::createTypedArrayIteratorObject): (JSC::typedArrayViewProtoFuncValues): (JSC::typedArrayProtoViewFuncEntries): (JSC::typedArrayViewProtoFuncKeys): (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/VM.cpp: * runtime/VM.h: 2020-01-08 Michael Saboff Instruction.h: Multiplication result converted to larger type https://bugs.webkit.org/show_bug.cgi?id=205945 Reviewed by Mark Lam. * bytecode/Instruction.h: (JSC::BaseInstruction::size const): Changed the types to size_t so that the computation is computed accordingly. 2020-01-08 Yusuke Suzuki Reduce binary size by purging C++ type information in Objective-C fields and parameters https://bugs.webkit.org/show_bug.cgi?id=205905 Reviewed by Saam Barati. * API/JSWrapperMap.mm: (-[JSObjCClassInfo dealloc]): 2020-01-08 Saam Barati build-jsc should invoke make instead of calling xcodebuild directly https://bugs.webkit.org/show_bug.cgi?id=205960 Reviewed by Keith Miller. The various jsc, and test* binaries can all be compiled in parallel. This patch makes that happen when building with make via the CLI that these are built in parallel. To make this work, in Xcode, I needed to mark these binaries as depending on JavaScriptCore.framework. * JavaScriptCore.xcodeproj/project.pbxproj: * Makefile: 2020-01-08 Tuomas Karkkainen Add FuzzerAgents that narrow and widen number predictions https://bugs.webkit.org/show_bug.cgi?id=203993 Reviewed by Yusuke Suzuki. Add two FuzzerAgents such that for any predictions that are originally subsets of SpecFullNumber: - one adds more number types to the prediction - the other removes some of the number types from the prediction * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * runtime/NarrowingNumberPredictionFuzzerAgent.cpp: Added. * runtime/NarrowingNumberPredictionFuzzerAgent.h: Added. * runtime/NumberPredictionFuzzerAgent.cpp: Added. * runtime/NumberPredictionFuzzerAgent.h: Added. * runtime/OptionsList.h: * runtime/VM.cpp: * runtime/WideningNumberPredictionFuzzerAgent.cpp: Added. * runtime/WideningNumberPredictionFuzzerAgent.h: Added. 2020-01-08 Michael Saboff TypeProfiler.h: Multiplication result converted to larger type https://bugs.webkit.org/show_bug.cgi?id=205947 Reviewed by Mark Lam. Added cast to keep the hash() calculation unsigned. * runtime/TypeProfiler.h: (JSC::QueryKey::hash const): 2020-01-08 Michael Saboff JSArrayBufferView.h: Multiplication result converted to larger type https://bugs.webkit.org/show_bug.cgi?id=205943 Reviewed by Saam Barati. Added cast to size_t to make the whole calculation size_t. * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::sizeOf): 2020-01-08 Alexey Shvayka Proxy's [[OwnPropertyKeys]] is correct only in PropertyNameMode::StringsAndSymbols https://bugs.webkit.org/show_bug.cgi?id=205772 Reviewed by Ross Kirsling. This change fixes two spec compatibility issues: (steps 8-11 of https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys) 1. If Object.getOwnPropertyNames is called on Proxy with "ownKeys" trap, symbol keys of Proxy's target are ignored during invariants validation. 2. If Object.getOwnPropertySymbols is called on Proxy with "ownKeys" trap, string keys of Proxy's target are ignored during invariants validation. Given that per spec `uncheckedResultKeys` contains both strings and symbols, `seenKeys` and explanation comment about it is removed. Specifying PrivateSymbolMode::Exclude eliminates any chance of false TypeErrors during invariants validation, since user code can't possibly return a private symbol from "ownKeys" trap, yet an object with private symbols can be Proxy's target. * runtime/ProxyObject.cpp: (JSC::ProxyObject::performGetOwnPropertyNames): 2020-01-08 Alexey Shvayka RegExp.prototype[Symbol.replace] does not support named capture groups https://bugs.webkit.org/show_bug.cgi?id=205783 Reviewed by Ross Kirsling. This patch adds named capture groups support to RegExp.prototype[Symbol.replace], for both functional and string pattern replacement. (steps 14.j-l of https://tc39.es/ecma262/#sec-regexp.prototype-@@replace) This method is used in slow path of String.prototype.replace (RegExp subclass handling), yet it also can be invoked directly in user code. * builtins/RegExpPrototype.js: (getSubstitution): (Symbol.replace): 2020-01-07 Saam Barati AI rule for ValueMod/ValueDiv produce constants with the wrong format when the result can be an int32 https://bugs.webkit.org/show_bug.cgi?id=205906 Reviewed by Yusuke Suzuki. The runtime code for ValueMod and ValueDiv produces an int32 when the result is of int32 value. However, the AI was saying the result is in double format. This patch fixes AI to produce a JSValue in the right format. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::handleConstantDivOp): 2020-01-07 Said Abou-Hallawa Implement css3-images image-orientation https://bugs.webkit.org/show_bug.cgi?id=89052 Reviewed by Simon Fraser. Remove the ENABLE_CSS_IMAGE_ORIENTATION feature flag. * Configurations/FeatureDefines.xcconfig: 2020-01-07 Ross Kirsling Unreviewed restabilization of non-unified build. * bytecode/MethodOfGettingAValueProfile.h: * dfg/DFGVariableEvent.h: * dfg/DFGVariableEventStream.cpp: * interpreter/CheckpointOSRExitSideState.h: 2020-01-07 Yusuke Suzuki [JSC] Remove vm accessor in JSVirtualMachine to reduce binary size https://bugs.webkit.org/show_bug.cgi?id=205880 Reviewed by Mark Lam. Objective-C has reflection mechanism. This means that fields, methods, and their types need to hold its string representations in binary even if we are using release build. While typical Objective-C class does not have large size of type names, C++ struct / class has very large one, and putting them in Objective-C method names, parameter types, or fields makes binary size very large. By analyzing JavaScriptCore binary, I found that Objective-C method type symbols are taking 200~KB binary size. (Section __objc_methtype: 235081 (addr 0x105e9a3 offset 17164707)). And it is due to JSC::VM type included in `[JSVirtualMachine vm]` accessor. This patch removes this accessor and gets 200KB binary size reduction. * API/JSScript.mm: (-[JSScript readCache]): (-[JSScript sourceCode]): (-[JSScript jsSourceCode]): (-[JSScript writeCache:]): * API/JSVirtualMachine.mm: (-[JSVirtualMachine JSContextGroupRef]): (-[JSVirtualMachine isWebThreadAware]): (-[JSVirtualMachine vm]): Deleted. * API/JSVirtualMachineInternal.h: 2020-01-07 Keith Miller Unreviewed non-arm64e build fix. * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): 2020-01-07 Keith Miller Bytecode checkpoint fixes for arm64(e) https://bugs.webkit.org/show_bug.cgi?id=205871 Reviewed by Michael Saboff. The original bytecode checkpoint patch had a couple of bugs on arm64(e). For arm64 generally, when osr exiting to an inline varargs frame we didn't set the return value of callee before moving the call frame register into a0 for the slow path call. This meant we clobber the return value on arm64 as a0 == r0. On arm64e the osr exit compiler set the tag for the return pc for an inline frame to JSEntryTag but the code expected NoTag. Additionally, in the stack unwinder, we were using the JSEntryTag but we should have been stripping the tag from the stack value. * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGOSRExitCompilerCommon.h: * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::operator() const): * llint/LowLevelInterpreter.asm: 2020-01-07 Chris Fleizach AX: Enable ACCESSIBILITY_ISOLATED_TREE https://bugs.webkit.org/show_bug.cgi?id=205535 Reviewed by Zalan Bujtas. * Configurations/FeatureDefines.xcconfig: 2020-01-06 Yoshiaki Jitsukawa [PlayStation] Update port cmake https://bugs.webkit.org/show_bug.cgi?id=205846 Reviewed by Don Olmstead. * PlatformPlayStation.cmake: Workaround of compilation errors with VisualStudio generator, which gives -std=c++* options to C sources. 2020-01-06 Alexey Shvayka String.prototype.replace() incorrectly handles named references on RegExp w/o named groups https://bugs.webkit.org/show_bug.cgi?id=205785 Reviewed by Ross Kirsling. This patch fixes substitution of named references by ignoring "$<" sequences for a RegExp without named capture groups, removing some index tweaking. (step 11 of https://tc39.es/ecma262/#sec-getsubstitution) Also this change removes 2 obsolete FIXMEs regarding possible spec changes. * runtime/StringPrototype.cpp: (JSC::substituteBackreferencesSlow): 2020-01-06 Mark Lam Convert ASSERT_DISABLED to ASSERT_ENABLED, and fix some tests of NDEBUG that should actually test for ASSERT_ENABLED. https://bugs.webkit.org/show_bug.cgi?id=205776 Reviewed by Saam Barati. * API/tests/testapi.c: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::replaceWithLoad): (JSC::ARM64Assembler::replaceWithAddressComputation): * assembler/AssemblerBuffer.h: (JSC::AssemblerBuffer::LocalWriter::LocalWriter): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * assembler/ProbeStack.cpp: (JSC::Probe::Stack::Stack): * assembler/ProbeStack.h: * b3/B3FoldPathConstants.cpp: * b3/B3LowerToAir.cpp: * b3/B3MemoryValue.cpp: (JSC::B3::MemoryValue::MemoryValue): * b3/B3Opcode.cpp: * b3/B3Type.h: * b3/B3TypeMap.h: * b3/B3Width.h: * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration): (JSC::B3::Air::GenerateAndAllocateRegisters::generate): * b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirArg.cpp: * b3/air/AirArg.h: * b3/air/AirCode.h: * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::emitShuffle): * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createExecutable): * bytecode/AccessCase.cpp: * bytecode/AccessCase.h: * bytecode/CallVariant.cpp: (JSC::variantListWithVariant): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndex): * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::dump const): * bytecode/StructureStubInfo.cpp: * bytecode/StructureStubInfo.h: * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallResolveNode::emitBytecode): * bytecompiler/RegisterID.h: (JSC::RegisterID::RegisterID): (JSC::RegisterID::setIndex): * debugger/Debugger.cpp: (JSC::Debugger::removeBreakpoint): * debugger/DebuggerEvalEnabler.h: (JSC::DebuggerEvalEnabler::DebuggerEvalEnabler): (JSC::DebuggerEvalEnabler::~DebuggerEvalEnabler): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::observeTransitions): * dfg/DFGAbstractValue.cpp: * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::merge): (JSC::DFG::AbstractValue::checkConsistency const): (JSC::DFG::AbstractValue::assertIsRegistered const): * dfg/DFGArithMode.h: (JSC::DFG::doesOverflow): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::BasicBlock): * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::didLink): * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::performBlockCFA): * dfg/DFGCommon.h: (JSC::DFG::validationEnabled): * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::finalizeCatchEntrypoints): * dfg/DFGDesiredWatchpoints.h: * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGEdge.h: (JSC::DFG::Edge::makeWord): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::finalizeOSREntrypoints): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::assertClear): * dfg/DFGSlowPathGenerator.h: (JSC::DFG::SlowPathGenerator::generate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse): (JSC::DFG::SpeculativeJIT::emitAllocateButterfly): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): (JSC::DFG::SpeculativeJIT::compileMakeRope): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateCell): * dfg/DFGStructureAbstractValue.cpp: * dfg/DFGStructureAbstractValue.h: (JSC::DFG::StructureAbstractValue::assertIsRegistered const): * dfg/DFGVarargsForwardingPhase.cpp: * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::callPreflight): (JSC::FTL::DFG::LowerDFGToB3::callCheck): (JSC::FTL::DFG::LowerDFGToB3::crash): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * heap/BlockDirectory.cpp: (JSC::BlockDirectory::assertNoUnswept): * heap/GCSegmentedArray.h: (JSC::GCArraySegment::GCArraySegment): * heap/GCSegmentedArrayInlines.h: (JSC::GCSegmentedArray::clear): (JSC::GCSegmentedArray::expand): (JSC::GCSegmentedArray::validatePrevious): * heap/HandleSet.cpp: * heap/HandleSet.h: * heap/Heap.cpp: (JSC::Heap::updateAllocationLimits): * heap/Heap.h: * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: (JSC::MarkedBlock::assertValidCell const): (JSC::MarkedBlock::assertMarksNotStale): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::beginMarking): (JSC::MarkedSpace::endMarking): (JSC::MarkedSpace::assertNoUnswept): * heap/PreciseAllocation.cpp: * heap/PreciseAllocation.h: (JSC::PreciseAllocation::assertValidCell const): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::SlotVisitor): (JSC::SlotVisitor::appendJSCellOrAuxiliary): * heap/SlotVisitor.h: * inspector/InspectorProtocolTypes.h: (Inspector::Protocol::BindingTraits>::assertValueHasExpectedType): * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration): (CppProtocolTypesImplementationGenerator): (CppProtocolTypesImplementationGenerator._generate_assertion_for_enum): * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: * interpreter/FrameTracers.h: (JSC::JITOperationPrologueCallFrameTracer::JITOperationPrologueCallFrameTracer): * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): * interpreter/Interpreter.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::prepareCallOperation): * jit/BinarySwitch.cpp: (JSC::BinarySwitch::BinarySwitch): * jit/CCallHelpers.h: (JSC::CCallHelpers::setupStubArgs): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::emitDeltaCheck): (JSC::CallFrameShuffler::prepareAny): * jit/JIT.cpp: (JSC::JIT::assertStackPointerOffset): (JSC::JIT::compileWithoutLinking): * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_loop_hint): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_from_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_from_scope): * jit/Repatch.cpp: (JSC::linkPolymorphicCall): * jit/ThunkGenerators.cpp: (JSC::emitPointerValidation): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntOfflineAsmConfig.h: * parser/Lexer.cpp: * parser/Lexer.h: (JSC::isSafeBuiltinIdentifier): (JSC::Lexer::lexExpectIdentifier): * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck): (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck): * runtime/Butterfly.h: (JSC::ContiguousData::ContiguousData): (JSC::ContiguousData::Data::Data): * runtime/HashMapImpl.h: (JSC::HashMapImpl::checkConsistency const): (JSC::HashMapImpl::assertBufferIsEmpty const): * runtime/JSCellInlines.h: (JSC::JSCell::methodTable const): * runtime/JSFunction.cpp: * runtime/JSFunction.h: (JSC::JSFunction::assertTypeInfoFlagInvariants): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): (JSC::JSFinalObject::visitChildren): * runtime/JSObjectInlines.h: (JSC::JSObject::validatePutOwnDataProperty): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::assertVariableIsInThisObject): * runtime/LiteralParser.cpp: (JSC::LiteralParser::Lexer::lex): * runtime/LiteralParser.h: * runtime/Operations.h: (JSC::scribbleFreeCells): * runtime/OptionsList.h: * runtime/VM.cpp: (JSC::VM::computeCanUseJIT): * runtime/VM.h: (JSC::VM::canUseJIT): * runtime/VarOffset.h: (JSC::VarOffset::checkSanity const): * runtime/WeakMapImpl.h: (JSC::WeakMapImpl::checkConsistency const): (JSC::WeakMapImpl::assertBufferIsEmpty const): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::validateInst): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::validationFail const): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::checkConsistency): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast): * wasm/WasmSectionParser.h: * wasm/WasmSections.h: * wasm/WasmSignatureInlines.h: (JSC::Wasm::SignatureInformation::get): * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::previousInstanceOffset const): 2020-01-06 Alexey Shvayka Proxy's [[OwnPropertyKeys]] is incorrect in DontEnumPropertiesMode::Exclude https://bugs.webkit.org/show_bug.cgi?id=203818 Reviewed by Keith Miller. This change fixes two spec compatibility issues: 1. If Object.keys is called on Proxy w/o "ownKeys" trap, filtering non-enumerable properties are not observed by "getOwnPropertyDescriptor" trap. (step 4 of https://tc39.es/ecma262/#sec-enumerableownpropertynames) 2. If Object.keys is called on Proxy with "ownKeys" trap, non-enumerable properties of Proxy's target are ignored during invariants validation. (step 11 of https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys) Instead of extracting DontEnum filtering to lambda function, a wrapper method for ProxyObject::performGetOwnPropertyNames was introduced to avoid creating & filling intermediate PropertyNameArray instance (in case of DontEnumPropertiesMode::Include) and avoid having inner EnumerationMode in ProxyObject::performGetOwnPropertyNames. * runtime/ProxyObject.cpp: (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::performGetOwnEnumerablePropertyNames): (JSC::ProxyObject::getOwnPropertyNames): * runtime/ProxyObject.h: 2020-01-05 Sam Weinig Further simplify StringBuilder usage by standardizing hex formating to a single hex() function https://bugs.webkit.org/show_bug.cgi?id=205759 Reviewed by Dean Jackson. * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::json): * runtime/JSGlobalObjectFunctions.cpp: (JSC::encode): (JSC::globalFuncEscape): Replace appendUnsignedAsHex() and appendByteAsHex() with append(hex()). 2020-01-05 Ross Kirsling JavaScript: Invalid date parse for ISO 8601 strings when no timezone given https://bugs.webkit.org/show_bug.cgi?id=89071 Reviewed by Darin Adler. Since ES2016, the specification for Date.parse has included the following statement: When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time. This patch updates us from the old ES5 behavior, which treated offsetless date-time forms as UTC. * runtime/JSDateMath.cpp: (JSC::parseDateFromNullTerminatedCharacters): (JSC::parseES5DateFromNullTerminatedCharacters): Added. (JSC::parseDate): * runtime/JSDateMath.h: Make a local time adjustment if necessary after calling WTF::parseES5DateFromNullTerminatedCharacters. 2020-01-04 Alexey Shvayka JSON.parse should initialize wrapper object with [[DefineOwnProperty]] https://bugs.webkit.org/show_bug.cgi?id=205767 Reviewed by Darin Adler. This patch makes JSON.parse use [[DefineOwnProperty]] instead of [[Set]] to initialize wrapper object, aligning JSC with the spec (step 7.c of https://tc39.es/ecma262/#sec-json.parse) and other engines. Performing [[Set]] was observable by a setter on Object.prototype (with empty String key). Also removes two extra exceptions checks. * runtime/JSONObject.cpp: (JSC::Stringifier::stringify): (JSC::Walker::walk): 2020-01-02 Yusuke Suzuki [JSC] MarkedBlock::Handle and BlockDirectory should be shrunk https://bugs.webkit.org/show_bug.cgi?id=205712 Reviewed by Mark Lam. This patch shrinks MarkedBlock::Handle and BlockDirectory by leveraging the fact that Vector's size and capacity is unsigned. In these data structures, we use `size_t` to hold a index, but this can be converted to unsigned since we guarantee that this never exceeds unsigned since these numbers are derived from Vector's size / capacity, or index inside MarkedBlock (which is up to 64KB in some architectures). MarkedBlock::Handle is allocated per MarkedBlock, and in Gmail, it takes 1MB. We can save some bytes just using `unsigned`. In addition, this patch removes `m_prev` and `m_next` fields in MarkedBlock::Handle since it is never used. * heap/AtomIndices.h: * heap/BlockDirectory.cpp: (JSC::BlockDirectory::findBlockForAllocation): (JSC::BlockDirectory::addBlock): * heap/IsoCellSet.cpp: (JSC::IsoCellSet::addSlow): (JSC::IsoCellSet::didResizeBits): (JSC::IsoCellSet::didRemoveBlock): * heap/IsoCellSet.h: * heap/IsoCellSetInlines.h: (JSC::IsoCellSet::forEachMarkedCell): (JSC::IsoCellSet::forEachMarkedCellInParallel): (JSC::IsoCellSet::forEachLiveCell): * heap/IsoSubspace.cpp: (JSC::IsoSubspace::didResizeBits): (JSC::IsoSubspace::didRemoveBlock): * heap/IsoSubspace.h: * heap/LocalAllocator.h: * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::didAddToDirectory): (JSC::MarkedBlock::Handle::didRemoveFromDirectory): * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::index const): * heap/Subspace.cpp: (JSC::Subspace::didResizeBits): (JSC::Subspace::didRemoveBlock): * heap/Subspace.h: 2020-01-03 Simon Fraser Add some shared schemes to the WebKit.xcworkspace https://bugs.webkit.org/show_bug.cgi?id=205698 Reviewed by Tim Horton. Make WebKit.xcworkspace show the following schemes by default: All Source All Tools WTF JavaScriptCore WebCore WebKit WebKitLegacy DumpRenderTree WebKitTestRunner TestWebKitAPI MiniBrowser MobileMiniBrowser. Also remove the MobileMiniBrowserUITests scheme. * JavaScriptCore.xcodeproj/xcshareddata/xcschemes/JavaScriptCore.xcscheme: Copied from Tools/MobileMiniBrowser/MobileMiniBrowser.xcodeproj/xcshareddata/xcschemes/MobileMiniBrowserUITests.xcscheme. 2020-01-03 Saam Barati B3::ReduceLoopStrength should not do range based iteration on a vector it's mutating https://bugs.webkit.org/show_bug.cgi?id=205703 Reviewed by Mark Lam. B3::ReduceLoopStrength had code that did: ``` for (BasicBlock* pred : loopPostfooter->predecessors()) loopPostfooter->removePredecessor(pred); ``` This is wrong, since it's doing a range based iteration over the vector it is mutating. The fix is to just do: ``` while (loopPostfooter->predecessors().size()) loopPostfooter->removePredecessor(loopPostfooter->predecessors()[0]); ``` * b3/B3ReduceLoopStrength.cpp: (JSC::B3::ReduceLoopStrength::reduceByteCopyLoopsToMemcpy): 2020-01-03 Saam Barati AI rule for PutById can only observe transitions when it watches the condition https://bugs.webkit.org/show_bug.cgi?id=205697 Reviewed by Yusuke Suzuki. There was a bug in AI where we were capturing a PutByIdStatus and emitting a structure transition in AI state based on the variants inside this PutByIdStatus. This, in principal, is a valid static analysis to perform. However, we can only do this if we ensure that the snapshot we have in the PutByIdStatus holds at runtime. We can do this by watching the property conditions for the various variants. AI forgot to watch these conditions. This patch fixes that. In practice, this also means we need to be slightly more strict about stating to AI when we transition since some object property conditions aren't watchable, and need to be verified at runtime via structure checks. This is ok in practice, since we'll emit the code to do that inside constant folding (constant folding was already doing this), which will continue to report the precise transition in the abstract state. * dfg/DFGAbstractInterpreter.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): 2020-01-02 Yusuke Suzuki and Simon Fraser Experiment: create lots of different malloc zones for easier accounting of memory use https://bugs.webkit.org/show_bug.cgi?id=186422 Reviewed by Saam Barati. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/AssemblerBuffer.cpp: Copied from Source/JavaScriptCore/bytecode/InstructionStream.cpp. * assembler/AssemblerBuffer.h: (JSC::AssemblerData::AssemblerData): (JSC::AssemblerData::operator=): (JSC::AssemblerData::~AssemblerData): (JSC::AssemblerData::grow): * bytecode/AccessCase.cpp: * bytecode/AccessCase.h: * bytecode/BytecodeBasicBlock.cpp: * bytecode/BytecodeBasicBlock.h: * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: * bytecode/InstructionStream.cpp: * bytecode/InstructionStream.h: * bytecode/PolymorphicAccess.cpp: * bytecode/PolymorphicAccess.h: * bytecode/UnlinkedMetadataTable.cpp: (JSC::UnlinkedMetadataTable::finalize): * bytecode/UnlinkedMetadataTable.h: * bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::link): (JSC::UnlinkedMetadataTable::unlink): * bytecode/ValueProfile.h: (JSC::ValueProfileAndVirtualRegisterBuffer::ValueProfileAndVirtualRegisterBuffer): * bytecode/Watchpoint.cpp: * bytecode/Watchpoint.h: * dfg/DFGBasicBlock.cpp: * dfg/DFGBasicBlock.h: * dfg/DFGNode.cpp: * dfg/DFGNode.h: * dfg/DFGSpeculativeJIT.cpp: * dfg/DFGSpeculativeJIT.h: * heap/BlockDirectory.cpp: * heap/BlockDirectory.h: * heap/FastMallocAlignedMemoryAllocator.cpp: (JSC::FastMallocAlignedMemoryAllocator::FastMallocAlignedMemoryAllocator): (JSC::FastMallocAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::FastMallocAlignedMemoryAllocator::freeAlignedMemory): (JSC::FastMallocAlignedMemoryAllocator::tryAllocateMemory): (JSC::FastMallocAlignedMemoryAllocator::freeMemory): (JSC::FastMallocAlignedMemoryAllocator::tryReallocateMemory): * heap/FastMallocAlignedMemoryAllocator.h: * heap/GCSegmentedArray.cpp: Copied from Source/JavaScriptCore/parser/SourceProviderCache.cpp. * heap/GCSegmentedArray.h: * heap/GCSegmentedArrayInlines.h: (JSC::GCArraySegment::create): (JSC::GCArraySegment::destroy): * heap/GigacageAlignedMemoryAllocator.cpp: (JSC::GigacageAlignedMemoryAllocator::GigacageAlignedMemoryAllocator): (JSC::GigacageAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::GigacageAlignedMemoryAllocator::freeAlignedMemory): (JSC::GigacageAlignedMemoryAllocator::tryAllocateMemory): (JSC::GigacageAlignedMemoryAllocator::freeMemory): (JSC::GigacageAlignedMemoryAllocator::tryReallocateMemory): * heap/GigacageAlignedMemoryAllocator.h: * heap/IsoAlignedMemoryAllocator.cpp: (JSC::IsoAlignedMemoryAllocator::IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::IsoAlignedMemoryAllocator::freeAlignedMemory): (JSC::IsoAlignedMemoryAllocator::tryAllocateMemory): (JSC::IsoAlignedMemoryAllocator::freeMemory): * heap/IsoAlignedMemoryAllocator.h: * heap/IsoSubspace.cpp: (JSC::IsoSubspace::IsoSubspace): * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: * heap/WeakBlock.cpp: (JSC::WeakBlock::create): (JSC::WeakBlock::destroy): * heap/WeakBlock.h: * jit/JITCode.cpp: * jit/JITCode.h: * jit/RegisterAtOffsetList.cpp: * jit/RegisterAtOffsetList.h: * parser/Nodes.cpp: * parser/Nodes.h: * parser/ParserArena.cpp: (JSC::ParserArena::deallocateObjects): (JSC::ParserArena::allocateFreeablePool): * parser/ParserArena.h: * parser/SourceProvider.cpp: * parser/SourceProvider.h: * parser/SourceProviderCache.cpp: * parser/SourceProviderCache.h: * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::create): * runtime/CachePayload.cpp: (JSC::CachePayload::makeMallocPayload): * runtime/CachePayload.h: * runtime/CachedBytecode.h: (JSC::CachedBytecode::create): * runtime/CachedTypes.cpp: (JSC::Encoder::release): (JSC::Encoder::Page::Page): (JSC::CachedVector::encode): (JSC::CachedVector::decode const): (JSC::CachedInstructionStream::decode const): * runtime/PropertyMapHashTable.h: (JSC::PropertyTable::rehash): * runtime/PropertyTable.cpp: (JSC::PropertyTable::PropertyTable): (JSC::PropertyTable::~PropertyTable): * runtime/SymbolTable.cpp: * runtime/SymbolTable.h: * runtime/VM.cpp: (JSC::VM::~VM): * runtime/VM.h: (JSC::ScratchBuffer::create): (JSC::VM::exceptionFuzzingBuffer): * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): * wasm/WasmInstance.h: * wasm/WasmTable.cpp: (JSC::Wasm::Table::Table): (JSC::Wasm::FuncRefTable::FuncRefTable): * wasm/WasmTable.h: 2020-01-02 Yusuke Suzuki REGRESSION (r253867): Six test262 tests broken https://bugs.webkit.org/show_bug.cgi?id=205583 Reviewed by Mark Lam. If a function has empty name, a bound function should have "bound " name. But Intl prototypes' bound functions are exceptions: these JSBoundFunctions have empty name. In this patch, we pass `nullptr` for the JSBoundFunction::create's nameMayBeNull parameter of Intl prototypes' bound functions, to generate empty string name for these bound functions instead of "bound "[1]. This fixes test262 failures. [1]: https://tc39.es/ecma402/#sec-collator-compare-functions * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototypeGetterCompare): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::create): (JSC::JSBoundFunction::JSBoundFunction): (JSC::JSBoundFunction::visitChildren): * runtime/JSBoundFunction.h: * runtime/JSFunction.cpp: (JSC::JSFunction::reifyLazyBoundNameIfNeeded): * runtime/SmallStrings.cpp: (JSC::SmallStrings::initializeCommonStrings): * runtime/SmallStrings.h: (JSC::SmallStrings::boundPrefixString const): 2020-01-02 Sam Weinig Simplify StringBuilder API/align with makeString by removing appendFixed* functions and using FormatNumber struct instead https://bugs.webkit.org/show_bug.cgi?id=205671 Reviewed by Alex Christensen. * API/tests/ExecutionTimeLimitTest.cpp: (testExecutionTimeLimit): * runtime/Options.cpp: (JSC::OptionReader::Option::dump const): Replace all uses of builder.appendFixedPrecisionNumber(...) with builder.append(FormattedNumber::fixedPrecision(...)). 2020-01-01 Mark Lam Declare some classes as final. https://bugs.webkit.org/show_bug.cgi?id=205670 Reviewed by Sam Weinig. There are a few "Status" classes, all of whom have static computeFor() methods. All of these classes do not have derived classes, and are independent of each others in terms of inheritance relationships. By explicitly declaring them as final, we can make it clear that a call to any unqualified computeFor() methods within one of these classes must be from the self class, and that external calls to any given computeFor() method qualified with a class name is defined in that class (and is not inherited from another class). This detail may already be known to folks who are familiar with these classes. Declaring them as final helps surface this independence for readers of the code who is not already in the know. * bytecode/CallLinkStatus.h: * bytecode/ComplexGetStatus.h: * bytecode/GetByStatus.h: * bytecode/InByIdStatus.h: * bytecode/InstanceOfStatus.h: * bytecode/PutByIdStatus.h: 2019-12-22 Jeff Miller Update user-visible copyright strings to include 2020 https://bugs.webkit.org/show_bug.cgi?id=205552 Reviewed by Darin Adler. * Info.plist: 2019-12-20 Darin Adler Tidy a bit of StringBuilder usage https://bugs.webkit.org/show_bug.cgi?id=205509 Reviewed by Sam Weinig. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): Remove unneeded check that duplicates range checking that StringBuilder::appendSubstring does. 2019-12-30 Yusuke Suzuki Unreviewed, build fix after r253904 https://bugs.webkit.org/show_bug.cgi?id=205553 * bytecompiler/BytecodeGeneratorBaseInlines.h: (JSC::BytecodeGeneratorBase::alignWideOpcode16): (JSC::BytecodeGeneratorBase::alignWideOpcode32): 2019-12-30 Carlos Alberto Lopez Perez REGRESSION(r253896): [GTK][WPE] Broke the build with GCC-7 https://bugs.webkit.org/show_bug.cgi?id=205649 Reviewed by Mark Lam. Add WTF_INTERNAL macro to explicitly adjust the symbol visibility. * llint/LLIntSlowPaths.h: 2019-12-29 Yusuke Suzuki [JSC] Remove WTF::loadLoadFence from JSFunction::rareData() https://bugs.webkit.org/show_bug.cgi?id=205625 Reviewed by Mark Lam. WTF::loadLoadFence() is not necessary when loading FunctionRareData from JSFunction since we ensured that stored FunctionRareData is already baked by emitting WTF::storeStoreFence(). * runtime/JSFunction.h: (JSC::JSFunction::rareData const): (JSC::JSFunction::rareData): Deleted. * runtime/JSFunctionInlines.h: (JSC::JSFunction::hasReifiedLength const): (JSC::JSFunction::hasReifiedName const): (JSC::JSFunction::areNameAndLengthOriginal): (JSC::JSFunction::ensureRareDataAndAllocationProfile): 2019-12-28 Yusuke Suzuki Unreviewed, rename `.executable` to `.isExecutable` https://bugs.webkit.org/show_bug.cgi?id=205554 * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2019-12-28 Yusuke Suzuki [JSC] JSFunction's m_executable / m_rareData should be merged https://bugs.webkit.org/show_bug.cgi?id=205554 Reviewed by Mark Lam. This patch merges JSFunction::m_executable and JSFunction::m_rareData fields into one JSFunction::m_executableOrRareData field. JSFunction is one of the most frequently allocated objects (e.g. it is common that anonymous JSFunction expression is used as a scope). If we can save sizeof(JSFunction), we can get great savings in memory usage. JSFunction::m_scope field is touched every time we execute this function. (op_get_scope, or obtaining JSGlobalObject for host functions). On the other hand, m_executable field can be skipped if JSFunction call is cached by CallLinkInfo. So compared to JSFunction::m_scope, this field is less frequently touched. So, we merge m_executable and m_rareData fields into one, m_executableOrRareData. When it holds ExecutableBase*, we do nothing. But when we create FunctionRareData, we put ExecutableBase in FunctionRareData and store FunctionRareData to JSFunction::m_executableOrRareData field with `0x1` flag. This patch reduces sizeof(JSFunction) from 48 to 32. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): (JSC::DFG::SpeculativeJIT::compileGetExecutable): (JSC::DFG::SpeculativeJIT::compileCreateThis): (JSC::DFG::SpeculativeJIT::compileCreatePromise): (JSC::DFG::SpeculativeJIT::compileCreateInternalFieldObject): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable): (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): (JSC::FTL::DFG::LowerDFGToB3::compileCreateThis): (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_create_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_create_this): * jit/Repatch.cpp: (JSC::linkPolymorphicCall): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::boundFunctionCallGenerator): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::create): (JSC::FunctionRareData::visitChildren): (JSC::FunctionRareData::FunctionRareData): * runtime/FunctionRareData.h: * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::create): (JSC::JSBoundFunction::JSBoundFunction): * runtime/JSBoundFunction.h: * runtime/JSCustomGetterSetterFunction.cpp: (JSC::JSCustomGetterSetterFunction::JSCustomGetterSetterFunction): (JSC::JSCustomGetterSetterFunction::create): * runtime/JSCustomGetterSetterFunction.h: * runtime/JSFunction.cpp: (JSC::JSFunction::create): (JSC::JSFunction::createFunctionThatMasqueradesAsUndefined): (JSC::JSFunction::JSFunction): (JSC::JSFunction::finishCreation): (JSC::JSFunction::allocateRareData): (JSC::JSFunction::allocateAndInitializeRareData): (JSC::JSFunction::initializeRareData): (JSC::JSFunction::visitChildren): (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * runtime/JSFunction.h: (JSC::JSFunction::executable const): (JSC::JSFunction::offsetOfExecutableOrRareData): (JSC::JSFunction::rareData): (JSC::JSFunction::offsetOfExecutable): Deleted. (JSC::JSFunction::offsetOfRareData): Deleted. * runtime/JSFunctionInlines.h: (JSC::JSFunction::JSFunction): (JSC::JSFunction::jsExecutable const): (JSC::JSFunction::isHostFunction const): (JSC::JSFunction::nativeFunction): (JSC::JSFunction::nativeConstructor): (JSC::JSFunction::hasReifiedLength const): (JSC::JSFunction::hasReifiedName const): (JSC::JSFunction::areNameAndLengthOriginal): (JSC::JSFunction::ensureRareDataAndAllocationProfile): * runtime/JSNativeStdFunction.cpp: (JSC::JSNativeStdFunction::JSNativeStdFunction): (JSC::JSNativeStdFunction::create): * runtime/JSNativeStdFunction.h: * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::create): (JSC::WebAssemblyFunction::WebAssemblyFunction): * wasm/js/WebAssemblyFunction.h: * wasm/js/WebAssemblyFunctionBase.cpp: (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase): * wasm/js/WebAssemblyFunctionBase.h: * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction): (JSC::WebAssemblyWrapperFunction::create): * wasm/js/WebAssemblyWrapperFunction.h: 2019-12-28 Yusuke Suzuki [JSC] StructureChain should hold vector of StructureID https://bugs.webkit.org/show_bug.cgi?id=205592 Reviewed by Mark Lam. StructureChain should keep vector of StructureID instead of Structure* to minimize the size of vector. * llint/LowLevelInterpreter64.asm: * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/ProxyObject.h: * runtime/Structure.cpp: (JSC::Structure::canCachePropertyNameEnumerator const): * runtime/Structure.h: * runtime/StructureChain.cpp: (JSC::StructureChain::StructureChain): (JSC::StructureChain::create): (JSC::StructureChain::finishCreation): (JSC::StructureChain::visitChildren): * runtime/StructureChain.h: * runtime/StructureInlines.h: (JSC::Structure::isValid const): 2019-12-25 Yusuke Suzuki [JSC] Compact Bytecodes more by emitting 1-byte Opcode https://bugs.webkit.org/show_bug.cgi?id=205553 Reviewed by Keith Miller. When emitting 16bit / 32bit bytecodes, we also emit 16bit / 32bit Opcode. So the layout is the following. 8bit 16bit 16bit 16bit - [op_wide16][ Opcode ][ Operand0 ][ Operand1 ] But this is unnecessary since Opcode must fit in 8bit. We should emit Opcode in 8bit in all cases. 8bit 8bit 16bit 16bit - [op_wide16][Opcode][ Operand0 ][ Operand1 ] * bytecode/Instruction.h: (JSC::BaseInstruction::size const): * bytecompiler/BytecodeGeneratorBaseInlines.h: (JSC::BytecodeGeneratorBase::alignWideOpcode16): (JSC::BytecodeGeneratorBase::alignWideOpcode32): * generator/Argument.rb: * generator/Opcode.rb: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * llint/WebAssembly.asm: 2019-12-24 Keith Miller Fix ARM64E by adding missing pointer tag. * llint/LowLevelInterpreter.asm: 2019-12-23 Keith Miller DFG/FTL should be able to exit to the middle of a bytecode https://bugs.webkit.org/show_bug.cgi?id=205232 Reviewed by Saam Barati. It can be valuable to exit to the middle of a bytecode for a couple of reasons. 1) It can be used to combine bytecodes that share a majority of their operands, reducing bytecode steam size. 2) It enables creating bytecodes that are easier to reconstruct useful optimization information from. To make exiting to the middle of a bytecode possible this patch introduces the concept of a temporary operand. A temporary operand is one that contains the result of effectful operations during the process of executing a bytecode. tmp operands have no meaning when executing in the LLInt or Baseline and are only used in the DFG to preserve information for OSR exit. We use the term checkpoint to refer to any point where an effectful component of a bytecode executes. For example, in op_call_varargs there are two checkpoints the first is before we have determined the number of variable arguments and the second is the actual call. When the DFG OSR exits if there are any active checkpoints inline call stack we will emit a jit probe that allocates a side state object keyed off the frame pointer of the bytecode whose checkpoint needs to be finished. We need side state because we may recursively inline several copies of the same function. Alternatively, we could call back into ourselves after OSR and exit again from optimized code before finishing the checkpoint of our caller. Another thing we need to be careful of is making sure we remove side state as we unwind for an exception. To make sure we do this correctly I've added an assertion to JSLock that there are no pending checkpoint side states on the vm when releasing the lock. A large amount of this patch is trying to remove as much code that refers to virtual registers as an int as possible. Instead, this patch replaces them with the VirtualRegister class. There are also a couple of new classes/enums added to JSC: 1) There is now a class, Operand, that represents the combination of a VirtualRegister and a temporary. This is handy in the DFG to model OSR exit values all together. Additionally, Operands has been updated to work with respect to Operand values. 2) CallFrameSlot is now an enum class instead of a struct of constexpr values. This lets us implicitly convert CallFrameSlots to VirtualRegisters without allowing all ints to implicity convert. 3) FTL::SelectPredictability is a new enum that describes to the FTL whether or not we think a select is going to be predictable. SelectPredictability has four options: Unpredictable, Predictable, LeftLikely, and RightLikely. Unpredictable means we think a branch predictor won't do a good job guessing this value so we should compile the select to a cmov. The other options mean we either think we are going to pick the same value every time or there's a reasonable chance the branch predictor will be able to guess the value. In order to validate the correctness of this patch the various varargs call opcodes have been reworked to use checkpoints. This also fixed a long-standing issue where we could call length getters twice if we OSR exit during LoadVarargs but before the actually call. Lastly, we have not enabled the probe-based OSR exit for a long time in production, thus this patch removes that code since it would be a non-trivial amount of work to get checkpoints working with probe OSR. * CMakeLists.txt: * DerivedSources-input.xcfilelist: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssemblerCodeRef.h: * assembler/ProbeFrame.h: (JSC::Probe::Frame::operand): (JSC::Probe::Frame::setOperand): * b3/testb3.h: (populateWithInterestingValues): (floatingPointOperands): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/AccessCaseSnippetParams.cpp: (JSC::SlowPathCallGeneratorWithArguments::generateImpl): * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumperBase::dumpValue): (JSC::BytecodeDumper::registerName const): (JSC::BytecodeDumper::constantName const): (JSC::Wasm::BytecodeDumper::constantName const): * bytecode/BytecodeDumper.h: * bytecode/BytecodeIndex.cpp: (JSC::BytecodeIndex::dump const): * bytecode/BytecodeIndex.h: (JSC::BytecodeIndex::BytecodeIndex): (JSC::BytecodeIndex::offset const): (JSC::BytecodeIndex::checkpoint const): (JSC::BytecodeIndex::asBits const): (JSC::BytecodeIndex::hash const): (JSC::BytecodeIndex::operator bool const): (JSC::BytecodeIndex::pack): (JSC::BytecodeIndex::fromBits): * bytecode/BytecodeList.rb: * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::enumValuesEqualAsIntegral): (JSC::tmpLivenessForCheckpoint): * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::virtualRegisterIsAlwaysLive): (JSC::virtualRegisterThatIsNotAlwaysLiveIsLive): (JSC::virtualRegisterIsLive): (JSC::operandIsAlwaysLive): Deleted. (JSC::operandThatIsNotAlwaysLiveIsLive): Deleted. (JSC::operandIsLive): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::bytecodeIndexForExit const): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndexSlow): (JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness): * bytecode/CodeBlock.h: (JSC::CodeBlock::numTmps const): (JSC::CodeBlock::isKnownNotImmediate): (JSC::CodeBlock::isTemporaryRegister): (JSC::CodeBlock::constantRegister): (JSC::CodeBlock::getConstant const): (JSC::CodeBlock::constantSourceCodeRepresentation const): (JSC::CodeBlock::replaceConstant): (JSC::CodeBlock::isTemporaryRegisterIndex): Deleted. (JSC::CodeBlock::isConstantRegisterIndex): Deleted. * bytecode/CodeOrigin.h: * bytecode/FullBytecodeLiveness.h: (JSC::FullBytecodeLiveness::virtualRegisterIsLive const): (JSC::FullBytecodeLiveness::operandIsLive const): Deleted. * bytecode/InlineCallFrame.h: (JSC::InlineCallFrame::InlineCallFrame): (JSC::InlineCallFrame::setTmpOffset): (JSC::CodeOrigin::walkUpInlineStack const): (JSC::CodeOrigin::inlineStackContainsActiveCheckpoint const): (JSC::remapOperand): (JSC::unmapOperand): (JSC::CodeOrigin::walkUpInlineStack): Deleted. * bytecode/LazyOperandValueProfile.h: (JSC::LazyOperandValueProfileKey::LazyOperandValueProfileKey): (JSC::LazyOperandValueProfileKey::hash const): (JSC::LazyOperandValueProfileKey::operand const): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::fromLazyOperand): (JSC::MethodOfGettingAValueProfile::emitReportValue const): (JSC::MethodOfGettingAValueProfile::reportValue): * bytecode/MethodOfGettingAValueProfile.h: * bytecode/Operands.h: (JSC::Operand::Operand): (JSC::Operand::tmp): (JSC::Operand::kind const): (JSC::Operand::value const): (JSC::Operand::virtualRegister const): (JSC::Operand::asBits const): (JSC::Operand::isTmp const): (JSC::Operand::isArgument const): (JSC::Operand::isLocal const): (JSC::Operand::isHeader const): (JSC::Operand::isConstant const): (JSC::Operand::toArgument const): (JSC::Operand::toLocal const): (JSC::Operand::operator== const): (JSC::Operand::isValid const): (JSC::Operand::fromBits): (JSC::Operands::Operands): (JSC::Operands::numberOfLocals const): (JSC::Operands::numberOfTmps const): (JSC::Operands::tmpIndex const): (JSC::Operands::argumentIndex const): (JSC::Operands::localIndex const): (JSC::Operands::tmp): (JSC::Operands::tmp const): (JSC::Operands::argument): (JSC::Operands::argument const): (JSC::Operands::local): (JSC::Operands::local const): (JSC::Operands::sizeFor const): (JSC::Operands::atFor): (JSC::Operands::atFor const): (JSC::Operands::ensureLocals): (JSC::Operands::ensureTmps): (JSC::Operands::getForOperandIndex): (JSC::Operands::getForOperandIndex const): (JSC::Operands::operandIndex const): (JSC::Operands::operand): (JSC::Operands::operand const): (JSC::Operands::hasOperand const): (JSC::Operands::setOperand): (JSC::Operands::at const): (JSC::Operands::at): (JSC::Operands::operator[] const): (JSC::Operands::operator[]): (JSC::Operands::operandForIndex const): (JSC::Operands::operator== const): (JSC::Operands::isArgument const): Deleted. (JSC::Operands::isLocal const): Deleted. (JSC::Operands::virtualRegisterForIndex const): Deleted. (JSC::Operands::setOperandFirstTime): Deleted. * bytecode/OperandsInlines.h: (JSC::Operand::dump const): (JSC::Operands::dumpInContext const): (JSC::Operands::dump const): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::hasCheckpoints const): (JSC::UnlinkedCodeBlock::setHasCheckpoints): (JSC::UnlinkedCodeBlock::constantRegister const): (JSC::UnlinkedCodeBlock::getConstant const): (JSC::UnlinkedCodeBlock::isConstantRegisterIndex const): Deleted. * bytecode/ValueProfile.h: (JSC::ValueProfileAndVirtualRegisterBuffer::ValueProfileAndVirtualRegisterBuffer): (JSC::ValueProfileAndVirtualRegisterBuffer::~ValueProfileAndVirtualRegisterBuffer): (JSC::ValueProfileAndOperandBuffer::ValueProfileAndOperandBuffer): Deleted. (JSC::ValueProfileAndOperandBuffer::~ValueProfileAndOperandBuffer): Deleted. (JSC::ValueProfileAndOperandBuffer::forEach): Deleted. * bytecode/ValueRecovery.cpp: (JSC::ValueRecovery::recover const): * bytecode/ValueRecovery.h: * bytecode/VirtualRegister.h: (JSC::virtualRegisterIsLocal): (JSC::virtualRegisterIsArgument): (JSC::VirtualRegister::VirtualRegister): (JSC::VirtualRegister::isValid const): (JSC::VirtualRegister::isLocal const): (JSC::VirtualRegister::isArgument const): (JSC::VirtualRegister::isConstant const): (JSC::VirtualRegister::toConstantIndex const): (JSC::operandIsLocal): Deleted. (JSC::operandIsArgument): Deleted. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::initializeNextParameter): (JSC::BytecodeGenerator::initializeParameters): (JSC::BytecodeGenerator::emitEqualityOpImpl): (JSC::BytecodeGenerator::emitCallVarargs): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::setUsesCheckpoints): * bytecompiler/RegisterID.h: (JSC::RegisterID::setIndex): * dfg/DFGAbstractHeap.cpp: (JSC::DFG::AbstractHeap::Payload::dumpAsOperand const): (JSC::DFG::AbstractHeap::dump const): * dfg/DFGAbstractHeap.h: (JSC::DFG::AbstractHeap::Payload::Payload): (JSC::DFG::AbstractHeap::AbstractHeap): (JSC::DFG::AbstractHeap::operand const): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentPosition.h: (JSC::DFG::ArgumentPosition::dump): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArgumentsUtilities.cpp: (JSC::DFG::argumentsInvolveStackSlot): (JSC::DFG::emitCodeToGetArgumentsArrayLength): * dfg/DFGArgumentsUtilities.h: * dfg/DFGAtTailAbstractState.h: (JSC::DFG::AtTailAbstractState::operand): * dfg/DFGAvailabilityMap.cpp: (JSC::DFG::AvailabilityMap::pruneByLiveness): * dfg/DFGAvailabilityMap.h: (JSC::DFG::AvailabilityMap::closeStartingWithLocal): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::BasicBlock): (JSC::DFG::BasicBlock::ensureTmps): * dfg/DFGBasicBlock.h: * dfg/DFGBlockInsertionSet.cpp: (JSC::DFG::BlockInsertionSet::insert): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ByteCodeParser): (JSC::DFG::ByteCodeParser::ensureTmps): (JSC::DFG::ByteCodeParser::progressToNextCheckpoint): (JSC::DFG::ByteCodeParser::newVariableAccessData): (JSC::DFG::ByteCodeParser::getDirect): (JSC::DFG::ByteCodeParser::get): (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getLocalOrTmp): (JSC::DFG::ByteCodeParser::setLocalOrTmp): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::findArgumentPosition): (JSC::DFG::ByteCodeParser::flushImpl): (JSC::DFG::ByteCodeParser::flushForTerminalImpl): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::flushDirect): (JSC::DFG::ByteCodeParser::addFlushOrPhantomLocal): (JSC::DFG::ByteCodeParser::phantomLocalDirect): (JSC::DFG::ByteCodeParser::flushForTerminal): (JSC::DFG::ByteCodeParser::addToGraph): (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand const): (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute): (JSC::DFG::ByteCodeParser::allocateTargetableBlock): (JSC::DFG::ByteCodeParser::allocateUntargetableBlock): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parse): (JSC::DFG::ByteCodeParser::getLocal): Deleted. (JSC::DFG::ByteCodeParser::setLocal): Deleted. * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::injectOSR): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::run): (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocal): (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocal): (JSC::DFG::CPSRethreadingPhase::canonicalizeSet): (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock): (JSC::DFG::CPSRethreadingPhase::propagatePhis): (JSC::DFG::CPSRethreadingPhase::phiStackFor): * dfg/DFGCSEPhase.cpp: * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCombinedLiveness.cpp: (JSC::DFG::addBytecodeLiveness): * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::addCodeOrigin): (JSC::DFG::CommonData::addUniqueCallSiteIndex): (JSC::DFG::CommonData::lastCallSite const): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGForAllKills.h: (JSC::DFG::forAllKilledOperands): (JSC::DFG::forAllKilledNodesAtNodeIndex): (JSC::DFG::forAllKillsInBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::dumpBlockHeader): (JSC::DFG::Graph::substituteGetLocal): (JSC::DFG::Graph::isLiveInBytecode): (JSC::DFG::Graph::localsAndTmpsLiveInBytecode): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): (JSC::DFG::Graph::localsLiveInBytecode): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::forAllLocalsAndTmpsLiveInBytecode): (JSC::DFG::Graph::forAllLiveInBytecode): (JSC::DFG::Graph::forAllLocalsLiveInBytecode): Deleted. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::InPlaceAbstractState): * dfg/DFGInPlaceAbstractState.h: (JSC::DFG::InPlaceAbstractState::operand): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::emitStoreCallSiteIndex): * dfg/DFGLiveCatchVariablePreservationPhase.cpp: (JSC::DFG::LiveCatchVariablePreservationPhase::isValidFlushLocation): (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch): (JSC::DFG::LiveCatchVariablePreservationPhase::newVariableAccessData): * dfg/DFGMovHintRemovalPhase.cpp: * dfg/DFGNode.h: (JSC::DFG::StackAccessData::StackAccessData): (JSC::DFG::Node::hasArgumentsChild): (JSC::DFG::Node::argumentsChild): (JSC::DFG::Node::operand): (JSC::DFG::Node::hasUnlinkedOperand): (JSC::DFG::Node::unlinkedOperand): (JSC::DFG::Node::hasLoadVarargsData): (JSC::DFG::Node::local): Deleted. (JSC::DFG::Node::hasUnlinkedLocal): Deleted. (JSC::DFG::Node::unlinkedLocal): Deleted. * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): (JSC::DFG::prepareCatchOSREntry): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::emitRestoreArguments): (JSC::DFG::OSRExit::compileExit): (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: * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::isExitingToCheckpointHandler const): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGOpInfo.h: (JSC::DFG::OpInfo::OpInfo): * dfg/DFGOperations.cpp: * dfg/DFGPhantomInsertionPhase.cpp: * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::read): (JSC::DFG::PreciseLocalClobberizeAdaptor::write): (JSC::DFG::PreciseLocalClobberizeAdaptor::def): (JSC::DFG::PreciseLocalClobberizeAdaptor::callIfAppropriate): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGPutStackSinkingPhase.cpp: * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::compileVarargsLength): (JSC::DFG::SpeculativeJIT::compileLoadVarargs): (JSC::DFG::SpeculativeJIT::compileForwardVarargs): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::recordSetLocal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): (JSC::DFG::StackLayoutPhase::assign): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitThunkGenerator): Deleted. * dfg/DFGThunks.h: * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries): * dfg/DFGValidate.cpp: * dfg/DFGVarargsForwardingPhase.cpp: * dfg/DFGVariableAccessData.cpp: (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): (JSC::DFG::VariableAccessData::tallyVotesForShouldUseDoubleFormat): (JSC::DFG::VariableAccessData::couldRepresentInt52Impl): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::operand): (JSC::DFG::VariableAccessData::local): Deleted. * dfg/DFGVariableEvent.cpp: (JSC::DFG::VariableEvent::dump const): * dfg/DFGVariableEvent.h: (JSC::DFG::VariableEvent::spill): (JSC::DFG::VariableEvent::setLocal): (JSC::DFG::VariableEvent::movHint): (JSC::DFG::VariableEvent::spillRegister const): (JSC::DFG::VariableEvent::operand const): (JSC::DFG::VariableEvent::bytecodeRegister const): Deleted. * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::logEvent): (JSC::DFG::VariableEventStream::reconstruct const): * dfg/DFGVariableEventStream.h: (JSC::DFG::VariableEventStream::appendAndLog): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLForOSREntryJITCode.cpp: (JSC::FTL::ForOSREntryJITCode::ForOSREntryJITCode): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileExtractOSREntryLocal): (JSC::FTL::DFG::LowerDFGToB3::compileGetStack): (JSC::FTL::DFG::LowerDFGToB3::compileGetCallee): (JSC::FTL::DFG::LowerDFGToB3::compileSetCallee): (JSC::FTL::DFG::LowerDFGToB3::compileSetArgumentCountIncludingThis): (JSC::FTL::DFG::LowerDFGToB3::compileVarargsLength): (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): (JSC::FTL::DFG::LowerDFGToB3::getSpreadLengthFromInlineCallFrame): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread): (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue): (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength): (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee): (JSC::FTL::DFG::LowerDFGToB3::callPreflight): (JSC::FTL::DFG::LowerDFGToB3::appendOSRExitDescriptor): (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): (JSC::FTL::DFG::LowerDFGToB3::addressFor): (JSC::FTL::DFG::LowerDFGToB3::payloadFor): (JSC::FTL::DFG::LowerDFGToB3::tagFor): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor): * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * ftl/FTLOutput.cpp: (JSC::FTL::Output::select): * ftl/FTLOutput.h: * ftl/FTLSelectPredictability.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp. * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * generator/Checkpoints.rb: Added. * generator/Opcode.rb: * generator/Section.rb: * heap/Heap.cpp: (JSC::Heap::gatherStackRoots): * interpreter/CallFrame.cpp: (JSC::CallFrame::callSiteAsRawBits const): (JSC::CallFrame::unsafeCallSiteAsRawBits const): (JSC::CallFrame::callSiteIndex const): (JSC::CallFrame::unsafeCallSiteIndex const): (JSC::CallFrame::setCurrentVPC): (JSC::CallFrame::bytecodeIndex): (JSC::CallFrame::codeOrigin): * interpreter/CallFrame.h: (JSC::CallSiteIndex::CallSiteIndex): (JSC::CallSiteIndex::operator bool const): (JSC::CallSiteIndex::operator== const): (JSC::CallSiteIndex::bits const): (JSC::CallSiteIndex::fromBits): (JSC::CallSiteIndex::bytecodeIndex const): (JSC::DisposableCallSiteIndex::DisposableCallSiteIndex): (JSC::CallFrame::callee const): (JSC::CallFrame::unsafeCallee const): (JSC::CallFrame::addressOfCodeBlock const): (JSC::CallFrame::argumentCountIncludingThis const): (JSC::CallFrame::offsetFor): (JSC::CallFrame::setArgumentCountIncludingThis): (JSC::CallFrame::setReturnPC): * interpreter/CallFrameInlines.h: (JSC::CallFrame::r): (JSC::CallFrame::uncheckedR): (JSC::CallFrame::guaranteedJSValueCallee const): (JSC::CallFrame::jsCallee const): (JSC::CallFrame::codeBlock const): (JSC::CallFrame::unsafeCodeBlock const): (JSC::CallFrame::setCallee): (JSC::CallFrame::setCodeBlock): * interpreter/CheckpointOSRExitSideState.h: Copied from Source/JavaScriptCore/dfg/DFGThunks.h. * interpreter/Interpreter.cpp: (JSC::eval): (JSC::sizeOfVarargs): (JSC::loadVarargs): (JSC::setupVarargsFrame): (JSC::UnwindFunctor::operator() const): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * interpreter/Interpreter.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readInlinedFrame): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr): (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32): (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64): (JSC::AssemblyHelpers::emitPutToCallFrameHeader): (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::addressFor): (JSC::AssemblyHelpers::tagFor): (JSC::AssemblyHelpers::payloadFor): (JSC::AssemblyHelpers::calleeFrameSlot): (JSC::AssemblyHelpers::calleeArgumentSlot): (JSC::AssemblyHelpers::calleeFrameTagSlot): (JSC::AssemblyHelpers::calleeFramePayloadSlot): (JSC::AssemblyHelpers::calleeFrameCallerFrame): (JSC::AssemblyHelpers::argumentCount): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::CallFrameShuffler): * jit/CallFrameShuffler.h: (JSC::CallFrameShuffler::setCalleeJSValueRegs): (JSC::CallFrameShuffler::assumeCalleeIsCell): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareAndJumpImpl): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsignedAndJumpImpl): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareUnsignedImpl): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_compareAndJumpSlowImpl): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emit_op_mod): (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitnot): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileOpCall): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITInlines.h: (JSC::JIT::isOperandConstantDouble): (JSC::JIT::getConstantOperand): (JSC::JIT::emitPutIntToCallFrameHeader): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResult): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::isOperandConstantChar): (JSC::JIT::getOperandConstantInt): (JSC::JIT::getOperandConstantDouble): (JSC::JIT::emitInitRegister): (JSC::JIT::emitLoadTag): (JSC::JIT::emitLoadPayload): (JSC::JIT::emitGet): (JSC::JIT::emitPutVirtualRegister): (JSC::JIT::emitLoad): (JSC::JIT::emitLoad2): (JSC::JIT::emitLoadDouble): (JSC::JIT::emitLoadInt32ToDouble): (JSC::JIT::emitStore): (JSC::JIT::emitStoreInt32): (JSC::JIT::emitStoreCell): (JSC::JIT::emitStoreBool): (JSC::JIT::emitStoreDouble): (JSC::JIT::emitJumpSlowCaseIfNotJSCell): (JSC::JIT::isOperandConstantInt): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitGetVirtualRegisters): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jundefined_or_null): (JSC::JIT::emit_op_jnundefined_or_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emit_op_throw): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_numeric): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_new_regexp): (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_array): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_argument): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emitResolveClosure): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emitLoadWithStructureCheck): (JSC::JIT::emitGetClosureVar): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emitPutGlobalVariable): (JSC::JIT::emitPutGlobalVariableIndirect): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emitWriteBarrier): (JSC::JIT::emit_op_get_internal_field): (JSC::JIT::emit_op_put_internal_field): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::emitLoadJSCell): (JSC::JSInterfaceJIT::emitJumpIfNotJSCell): (JSC::JSInterfaceJIT::emitLoadInt32): (JSC::JSInterfaceJIT::emitLoadDouble): (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr): (JSC::JSInterfaceJIT::emitPutToCallFrameHeader): (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadDoubleArgument): (JSC::SpecializedThunkJIT::loadCellArgument): (JSC::SpecializedThunkJIT::loadInt32Argument): * jit/ThunkGenerators.cpp: (JSC::absThunkGenerator): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::getNonConstantOperand): (JSC::LLInt::getOperand): (JSC::LLInt::genericCall): (JSC::LLInt::varargsSetup): (JSC::LLInt::commonCallEval): (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::handleVarargsCheckpoint): (JSC::LLInt::dispatchToNextInstruction): (JSC::LLInt::slow_path_checkpoint_osr_exit_from_inlined_call): (JSC::LLInt::slow_path_checkpoint_osr_exit): (JSC::LLInt::llint_throw_stack_overflow_error): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::fill): * runtime/CachedTypes.cpp: (JSC::CachedCodeBlock::hasCheckpoints const): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::CachedCodeBlock::encode): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/ConstructData.cpp: (JSC::construct): * runtime/ConstructData.h: * runtime/DirectArguments.cpp: (JSC::DirectArguments::copyToArguments): * runtime/DirectArguments.h: * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::copyToArguments): * runtime/JSArray.cpp: (JSC::JSArray::copyToArguments): * runtime/JSArray.h: * runtime/JSImmutableButterfly.cpp: (JSC::JSImmutableButterfly::copyToArguments): * runtime/JSImmutableButterfly.h: * runtime/JSLock.cpp: (JSC::JSLock::willReleaseLock): * runtime/ModuleProgramExecutable.cpp: (JSC::ModuleProgramExecutable::create): * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/ScopedArguments.cpp: (JSC::ScopedArguments::copyToArguments): * runtime/ScopedArguments.h: * runtime/VM.cpp: (JSC::VM::addCheckpointOSRSideState): (JSC::VM::findCheckpointOSRSideState): (JSC::VM::scanSideState const): * runtime/VM.h: (JSC::VM::hasCheckpointOSRSideState const): * tools/VMInspector.cpp: (JSC::VMInspector::dumpRegisters): * wasm/WasmFunctionCodeBlock.h: (JSC::Wasm::FunctionCodeBlock::getConstant const): (JSC::Wasm::FunctionCodeBlock::getConstantType const): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::setUsesCheckpoints const): * wasm/WasmOperations.cpp: (JSC::Wasm::operationWasmToJSException): * wasm/WasmSlowPaths.cpp: 2019-12-23 Yusuke Suzuki [JSC] Wasm OSR entry should capture top-most enclosing-stack https://bugs.webkit.org/show_bug.cgi?id=205571 Reviewed by Keith Miller. OSR entry should capture the top-most enclosing-stack too. Otherwise the def-node can be unreachable (since it is defined in BB which is unreachable from OSR entry point), and eliminated. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): (JSC::Wasm::AirIRGenerator::addLoop): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::addLoop): 2019-12-23 Carlos Garcia Campos WebDriver: fix handling of session timeouts for values higher than MAX_INT https://bugs.webkit.org/show_bug.cgi?id=204114 Reviewed by Brian Burg. Fix generation of code with optional number in stack variable. * inspector/scripts/codegen/cpp_generator.py: (CppGenerator.cpp_type_for_stack_in_parameter): Do not use Optional for numbers either. * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result: 2019-12-22 Yusuke Suzuki Unreviewed, fix incorrect merging https://bugs.webkit.org/show_bug.cgi?id=205327 r253862 and r253867 cause incorrect merging. This patch fixes it. * jit/ThunkGenerators.cpp: (JSC::boundFunctionCallGenerator): 2019-12-22 Yusuke Suzuki Unreviewed, fix debug failures due to missing exception checks https://bugs.webkit.org/show_bug.cgi?id=205327 * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnNonIndexPropertyNames): (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * runtime/JSObject.cpp: (JSC::JSObject::defineOwnNonIndexProperty): 2019-12-21 Yusuke Suzuki [JSC] Improve our bound function implementation https://bugs.webkit.org/show_bug.cgi?id=205327 Reviewed by Keith Miller. This patch improves Function#bind, and calling bound function with bound arguments. 1. Rename CallFrameSlot::argumentCount to CallFrameSlot::argumentCountIncludingThis. 2. Do not include name in NativeExecutable for JSBoundFunction. Putting name in NativeExecutable is assuming that function + name pair is almost identical. This is true in host functions except for JSBoundFunction. JSBoundFunction should hold its name in JSBoundFunction. 3. Cache NativeExecutable for JSBoundFunction in the VM. We use a hash-map in JITThunk for NativeExecutables because we assume that host-function creation cannot be done by the user program: each executable is pre-defined to exactly one object by the environment, and there is no way to create host-functions repeatedly from the user-program. The only exception to this is JSBoundFunction so caching it on the VM avoids the hash-map lookup. This is not true for JSBoundFunction. 4. ThunkGenerator should support JSBoundFunction call with bound arguments. It turns out that Speedometer2/React-Redux-TodoMVC is using bound function with bound arguments. Additionally, it is used. This is really bad: when dispatching an event, we first call this function from C++, entering JS world, going back to C++ world again, and entering JS world to call bound function again. By using ThunkGenerator, we can eliminate this back and forth by directly calling the bound JS Executable from the thunk. Previously, bound arguments are stored in JSArray. But it is difficult to access them from thunk since we need to consider have-a-bad-time case. Instead, we use JSImmutableButterfly to save bound arguments so that JIT thunk can quickly access arguments. To capture arguments as JSImmutableButterfly in JS world, we introduce op_create_arguments_butterfly, and handle it in all tiers. 5. It turns out that eager materialization of "length" in JSBoundFunction takes long time while it is rarely used. This patch makes length lazily reified for JSBoundFunction. 6. To make Function.prototype.bind faster, we track whether "name" and "length" properties of JSFunction is modified or not. This skips has-own-length-property check, which makes Function.prototype.bind 11~% faster. Combining things above, creation of JSBoundFunction is 80~% faster. And calling bound function with bound arguments is 3~x faster. This improves Speedometer2/React-TodoMVC by ~3%. * builtins/FunctionPrototype.js: (bind): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/AccessCaseSnippetParams.cpp: (JSC::SlowPathCallGeneratorWithArguments::generateImpl): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.rb: * bytecode/BytecodeUseDef.cpp: (JSC::computeUsesForBytecodeIndexImpl): (JSC::computeDefsForBytecodeIndexImpl): * bytecode/VirtualRegister.cpp: (JSC::VirtualRegister::dump const): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCreateArgumentsButterfly): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_createArgumentsButterfly): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArgumentsUtilities.cpp: (JSC::DFG::argumentsInvolveStackSlot): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::flushImpl): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::isLiveInBytecode): * dfg/DFGGraph.h: (JSC::DFG::Graph::forAllLocalsLiveInBytecode): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::emitStoreCallSiteIndex): * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode): * dfg/DFGOSRExit.cpp: (JSC::DFG::emitRestoreArguments): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::OSRExit::emitRestoreArguments): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCreateArgumentsButterfly): (JSC::DFG::SpeculativeJIT::compileGetArgumentCountIncludingThis): (JSC::DFG::SpeculativeJIT::compileSetArgumentCountIncludingThis): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCreateArgumentsButterfly): (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentCountIncludingThis): (JSC::FTL::DFG::LowerDFGToB3::compileSetArgumentCountIncludingThis): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength): (JSC::FTL::DFG::LowerDFGToB3::callPreflight): * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * interpreter/CallFrame.cpp: (JSC::CallFrame::callSiteAsRawBits const): (JSC::CallFrame::unsafeCallSiteAsRawBits const): (JSC::CallFrame::setCurrentVPC): * interpreter/CallFrame.h: (JSC::CallFrame::argumentCountIncludingThis const): (JSC::CallFrame::setArgumentCountIncludingThis): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitAssertArgumentCountSane): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::argumentCount): * jit/CCallHelpers.h: (JSC::CCallHelpers::prepareForTailCallSlow): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::dump const): (JSC::CallFrameShuffler::prepareForTailCall): (JSC::CallFrameShuffler::prepareAny): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::compileWithoutLinking): * jit/JITCall.cpp: (JSC::JIT::compileSetupFrame): (JSC::JIT::compileOpCall): * jit/JITCall32_64.cpp: (JSC::JIT::compileSetupFrame): (JSC::JIT::compileOpCall): * jit/JITInlines.h: (JSC::JIT::updateTopCallFrame): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_argument): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): * jit/ThunkGenerators.cpp: (JSC::arityFixupGenerator): (JSC::boundFunctionCallGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): Deleted. * jit/ThunkGenerators.h: * jsc.cpp: * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * llint/WebAssembly.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/ExecutableBase.h: * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::FunctionRareData): * runtime/FunctionRareData.h: * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototypeGetterCompare): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSBoundFunction.cpp: (JSC::boundThisNoArgsFunctionCall): (JSC::boundFunctionCall): (JSC::boundThisNoArgsFunctionConstruct): (JSC::boundFunctionConstruct): (JSC::JSBoundFunction::create): (JSC::JSBoundFunction::JSBoundFunction): (JSC::JSBoundFunction::boundArgsCopy): (JSC::JSBoundFunction::visitChildren): * runtime/JSBoundFunction.h: * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): (JSC::JSFunction::name): (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::getOwnNonIndexPropertyNames): (JSC::JSFunction::put): (JSC::JSFunction::deleteProperty): (JSC::JSFunction::defineOwnProperty): (JSC::JSFunction::reifyLength): (JSC::JSFunction::reifyLazyPropertyIfNeeded): (JSC::JSFunction::reifyLazyPropertyForHostOrBuiltinIfNeeded): (JSC::JSFunction::reifyLazyBoundNameIfNeeded): * runtime/JSFunction.h: * runtime/JSFunctionInlines.h: (JSC::JSFunction::areNameAndLengthOriginal): * runtime/JSGlobalObject.cpp: (JSC::makeBoundFunction): (JSC::hasOwnLengthProperty): * runtime/JSObject.h: (JSC::getJSFunction): (JSC::getCallData): Deleted. (JSC::getConstructData): Deleted. * runtime/JSObjectInlines.h: (JSC::getCallData): (JSC::getConstructData): * runtime/VM.cpp: (JSC::thunkGeneratorForIntrinsic): (JSC::VM::getBoundFunction): * runtime/VM.h: * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): 2019-12-20 Darin Adler Make JSString values from literals in a single consistent style https://bugs.webkit.org/show_bug.cgi?id=205517 Reviewed by Saam Barati. Some call sites did it like this: jsNontrivialString(vm, "literal"_s) Others did it one of these: jsString(vm, "literal") jsNontrivialString(vm, "literal") Changed all the call sites to do it the first, *slightly* more efficient, way. * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): * runtime/AsyncFunctionPrototype.cpp: (JSC::AsyncFunctionPrototype::finishCreation): * runtime/AsyncGeneratorFunctionPrototype.cpp: (JSC::AsyncGeneratorFunctionPrototype::finishCreation): * runtime/AsyncGeneratorPrototype.cpp: (JSC::AsyncGeneratorPrototype::finishCreation): * runtime/BigIntPrototype.cpp: (JSC::BigIntPrototype::finishCreation): * runtime/GeneratorFunctionPrototype.cpp: (JSC::GeneratorFunctionPrototype::finishCreation): * runtime/GeneratorPrototype.cpp: (JSC::GeneratorPrototype::finishCreation): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototype::finishCreation): * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::formatToParts): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::formatToParts): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): * runtime/IntlPluralRulesPrototype.cpp: (JSC::IntlPluralRulesPrototype::finishCreation): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::finishCreation): * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::finishCreation): * runtime/JSONObject.cpp: (JSC::JSONObject::finishCreation): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::finishCreation): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewProtoGetterFuncToStringTag): * runtime/MapIteratorPrototype.cpp: (JSC::MapIteratorPrototype::finishCreation): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/MathObject.cpp: (JSC::MathObject::finishCreation): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoGetterSource): * runtime/RegExpStringIteratorPrototype.cpp: (JSC::RegExpStringIteratorPrototype::finishCreation): * runtime/SetIteratorPrototype.cpp: (JSC::SetIteratorPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): * runtime/StringIteratorPrototype.cpp: (JSC::StringIteratorPrototype::finishCreation): * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): * runtime/WeakObjectRefPrototype.cpp: (JSC::WeakObjectRefPrototype::finishCreation): * runtime/WeakSetPrototype.cpp: (JSC::WeakSetPrototype::finishCreation): Call jsNontrivialString instead of jsString and use the _s suffix. 2019-12-21 Yusuke Suzuki [JSC] Remove m_globalObject field from JSFunction https://bugs.webkit.org/show_bug.cgi?id=205533 Reviewed by Mark Lam. JSFunction::m_globalObject is used only when it is using NativeExecutable. And when using NativeExecutable, JSCallee::m_scope is always pointing JSGlobalObject. This patch removes JSFunction::m_globalObject field. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSFunction.cpp: (JSC::JSFunction::JSFunction): * runtime/JSFunction.h: (JSC::JSFunction::offsetOfGlobalObject): Deleted. (JSC::JSFunction::globalObject const): Deleted. * runtime/JSFunctionInlines.h: (JSC::JSFunction::JSFunction): 2019-12-20 Ross Kirsling [JSC] Memory usage statistics should be attainable without WebCore https://bugs.webkit.org/show_bug.cgi?id=205366 Reviewed by Keith Miller. * API/JSBase.cpp: (JSGetMemoryUsageStatistics): * API/JSBasePrivate.h: Add a private JSC API exposing the same Heap stats as WebCore's PerformanceLogging::memoryUsageStatistics. 2019-12-19 Saam Barati Don't cache self customs on dictionaries https://bugs.webkit.org/show_bug.cgi?id=205466 Reviewed by Mark Lam. We had a bug where we would cache a custom value/accessor on a self property of a cacheable dictionary object. This turns out to be wrong because the inline cache won't fail (because we won't transition structures) if that property is replaced with something else. We would do the right thing when the custom was on the prototype chain, but when it was a self property, we didn't. The reason customs are different from values/normal accessors is that we dynamically load values/getters/setters from the object itself. For customs, we cache the actual pointer value of the C function. This patch makes it so we don't cache customs on dictionaries. * bytecode/ObjectPropertyConditionSet.cpp: (JSC::prepareChainForCaching): (JSC::preparePrototypeChainForCaching): Deleted. * bytecode/ObjectPropertyConditionSet.h: * jit/Repatch.cpp: (JSC::tryCacheGetBy): (JSC::tryCachePutByID): (JSC::tryCacheInByID): (JSC::tryCacheInstanceOf): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setupGetByIdPrototypeCache): * runtime/StructureRareData.cpp: (JSC::StructureRareData::setObjectToStringValue): 2019-12-19 Devin Rousso Web Inspector: TypeError: InjectedScriptHost.isPromiseRejectedWithNativeGetterTypeError first argument must be a Promise https://bugs.webkit.org/show_bug.cgi?id=205439 Reviewed by Brian Burg. Before r244312, we noticed that when Web Inspector would preview native getters that return a `Promise`, Web Inspector would prevent `rejectionhandled` events from being fired since it would always add a `.catch(() => {}` to any `Promise` that it was about to instrument in the Console to avoid errors being added to the Console while expanding/collapsing value previews. In order to prevent this, logic was added so that the `.catch(() => {})` was only added if the `Promise` was returned from a native getter, such as from a `PromiseRejectionEvent`. In r244312, we made it such that this logic _required_ the `Promise` to already be rejected, which is unnecessarily restrictive and not always the case nowadays. Instead, just check to see if the result of the `Promise` is a native getter type error. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): 2019-12-18 Devin Rousso Web Inspector: Elements: restrict showing paint flashing and compositing borders to the Web Inspector session https://bugs.webkit.org/show_bug.cgi?id=205201 Reviewed by Timothy Hatcher. We often get bugs from users who turn on paint flashing or compositing borders, close Web Inspector, reopen Web Inspector, and are then surprised when the page flashes red or these borders exist all over the page. Given that the dark mode and print styles toggles are limited to the Web Inspector session, we should make these have the same behavior. * inspector/protocol/Page.json: Allow Web Inspector to override the `showDebugBorders` and `showRepaintCounter` settings via the `inspectorOverride` key, rather than setting them manually via a special `Page` command. 2019-12-17 Yusuke Suzuki [JSC] 8Bit JSRopeString can contain 16Bit string in its rope https://bugs.webkit.org/show_bug.cgi?id=205323 Reviewed by Mark Lam. When resolving JSRopeString, it is possible that 8Bit JSRopeString becomes 16Bit resolved JSString. This happens when we attempt to resolve it to produce AtomicStringImpl, and 16Bit version of the resolved content is already in AtomicStringTable. This means that 16Bit flag never changes after resolving JSString, but that of JSRopeString is some sort of hint, which can be changed. This means that 8Bit JSRopeString can include 16Bit JSString, since some of children can be changed from 8Bit JSRopeString to resolved 16Bit JSString. Even in that case, we can still ensure that resolved string can be represented as 8Bit. Let's see the example. A => B + C, 8Bit Rope B => D + E, 8Bit Rope C => 8Bit String And when we convert B to 16Bit String since content of `D + E` is already registered as 16Bit String in AtomicStringTable. A => B + C, 8Bit Rope B => 16Bit String C => 8Bit String When resolving A, creating 8Bit string buffer is totally OK since we know that whole A string can be represented in 8Bit. When copying the content of B into 8Bit buffer, we should ignore upper 8Bit since they must be zero. In this patch, we completely share the implementation of resolveRopeInternalNoSubstring and resolveRopeSlowCase in 8Bit and 16Bit case: we take result buffer CharacterType, but the underlying code must check `is8Bit()` for each fiber. * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContextAssumingStructure const): * runtime/JSString.cpp: (JSC::JSRopeString::resolveRopeInternal8 const): (JSC::JSRopeString::resolveRopeInternal16 const): (JSC::JSRopeString::resolveRopeInternalNoSubstring const): (JSC::JSRopeString::resolveRopeWithFunction const): (JSC::JSRopeString::resolveRopeSlowCase const): (JSC::JSRopeString::resolveRopeInternal8NoSubstring const): Deleted. (JSC::JSRopeString::resolveRopeInternal16NoSubstring const): Deleted. (JSC::JSRopeString::resolveRopeSlowCase8 const): Deleted. * runtime/JSString.h: 2019-12-17 Carlos Garcia Campos [GLIB] jsc_context_evaluate_in_object should take the API lock before calling setGlobalScopeExtension https://bugs.webkit.org/show_bug.cgi?id=205331 Reviewed by Žan Doberšek. We are now getting a crash due to an assert because the api lock is not held. * API/glib/JSCContext.cpp: (jsc_context_evaluate_in_object): 2019-12-16 Mark Lam Relanding r253581: Changed jsc shell timeout mechanism to leverage the VMTraps and use CPUTime. https://bugs.webkit.org/show_bug.cgi?id=205279 Reviewed by Saam Barati. This fixes all the timeouts that occur due to CPU time starvation when running JSC tests on a debug build. What this means is that the timeout mechanism may trigger asynchronous OSR exits. If a test requires no OSR exits, that test should requireOption("--usePollingTraps=true") so that the VMTraps will use its polling implementation instead. I've tested this with a full run of the JSC stress tests with a debug build and saw 0 timeouts. I've also tested it with a contrived tests that loops forever, and saw the expected timeout crash. Will look into re-tuning needed timeout value (and other JSC tests timeout cleanup) in https://bugs.webkit.org/show_bug.cgi?id=205298. Update: in the previously landed patch, I did a last minute sort of the cases Int the switch statement in VMTraps::handleTraps() before posting my patch. This is incorrect to do since one of the cases need to fall through to another case. This patch undoes the sorting to the order I originally had the cases in during development and testing. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): * interpreter/InterpreterInlines.h: (JSC::Interpreter::execute): * jsc.cpp: (startTimeoutTimer): (timeoutCheckCallback): (initializeTimeoutIfNeeded): (startTimeoutThreadIfNeeded): (runJSC): (jscmain): * runtime/JSCConfig.h: * runtime/VM.h: (JSC::VM::notifyNeedShellTimeoutCheck): * runtime/VMTraps.cpp: (JSC::VMTraps::handleTraps): * runtime/VMTraps.h: (JSC::VMTraps::Mask::Mask): (JSC::VMTraps::Mask::allEventTypes): (JSC::VMTraps::Mask::init): (JSC::VMTraps::interruptingTraps): * tools/VMInspector.cpp: (JSC::VMInspector::forEachVM): * tools/VMInspector.h: 2019-12-16 Mark Lam Rolling out: r253581 is failing tests on a release build. https://bugs.webkit.org/show_bug.cgi?id=205279 Not reviewed. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): * interpreter/InterpreterInlines.h: (JSC::Interpreter::execute): * jsc.cpp: (startTimeoutThreadIfNeeded): (runJSC): (jscmain): (startTimeoutTimer): Deleted. (timeoutCheckCallback): Deleted. (initializeTimeoutIfNeeded): Deleted. * runtime/JSCConfig.h: * runtime/VM.h: (JSC::VM::notifyNeedDebuggerBreak): (JSC::VM::notifyNeedShellTimeoutCheck): Deleted. * runtime/VMTraps.cpp: (JSC::VMTraps::handleTraps): * runtime/VMTraps.h: (JSC::VMTraps::Mask::Mask): (JSC::VMTraps::Mask::allEventTypes): (JSC::VMTraps::Mask::init): (JSC::VMTraps::interruptingTraps): Deleted. * tools/VMInspector.cpp: (JSC::VMInspector::forEachVM): Deleted. * tools/VMInspector.h: 2019-12-16 Yusuke Suzuki ASSERTION FAILED: length <= maximumLength in js-fixed-array-out-of-memory.js https://bugs.webkit.org/show_bug.cgi?id=205259 Reviewed by Mark Lam. JSImmutableButterfly has moderate size limit on its length, while JSFixedArray does not. We should check this maximumLength when creating it in Spread. And if it exceeds, we should throw OOM error. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSpread): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileSpread): * runtime/ArrayConventions.h: * runtime/IndexingHeader.h: * runtime/JSImmutableButterfly.h: (JSC::JSImmutableButterfly::tryCreate): (JSC::JSImmutableButterfly::allocationSize): 2019-12-16 Yusuke Suzuki [JSC] Put non-dynamic scope cells in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=205311 Reviewed by Mark Lam. Put non-dynamic scope cells in IsoSubspace. - JSWithScope - StrictEvalActivation * runtime/JSScope.h: (JSC::JSScope::subspaceFor): * runtime/JSSymbolTableObject.h: * runtime/JSWithScope.h: * runtime/StrictEvalActivation.h: * runtime/VM.cpp: * runtime/VM.h: 2019-12-16 Yusuke Suzuki [JSC] Put DebuggerScope in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=205303 Reviewed by Mark Lam. Put DebuggerScope in IsoSubspace, and refine empty `subspaceFor` implementations. * bytecode/CodeBlock.h: (JSC::CodeBlock::subspaceFor): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::subspaceFor): * debugger/DebuggerScope.h: * runtime/AbstractModuleRecord.h: (JSC::AbstractModuleRecord::subspaceFor): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::subspaceFor): * runtime/JSInternalFieldObjectImpl.h: (JSC::JSInternalFieldObjectImpl::subspaceFor): * runtime/JSWrapperObject.h: (JSC::JSWrapperObject::subspaceFor): * runtime/VM.cpp: * runtime/VM.h: 2019-12-16 Yusuke Suzuki [JSC] Move JSCell::subspaceFor to JSObject::subspaceFor, removing destructibleCellSpace https://bugs.webkit.org/show_bug.cgi?id=205300 Reviewed by Mark Lam. All non-JSObject JSCells have their own IsoSubspace / CompleteSubspace. We remove JSCell::subspaceFor function, and move it to JSObject::subspaceFor. And we remove destructibleCellSpace since nobody uses it. * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::JSCell::subspaceFor): Deleted. * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSObject::subspaceFor): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-16 Mark Lam Changed jsc shell timeout mechanism to leverage the VMTraps and use CPUTime. https://bugs.webkit.org/show_bug.cgi?id=205279 Reviewed by Saam Barati. This fixes all the timeouts that occur due to CPU time starvation when running JSC tests on a debug build. What this means is that the timeout mechanism may trigger asynchronous OSR exits. If a test requires no OSR exits, that test should requireOption("--usePollingTraps=true") so that the VMTraps will use its polling implementation instead. I've tested this with a full run of the JSC stress tests with a debug build and saw 0 timeouts. I've also tested it with a contrived tests that loops forever, and saw the expected timeout crash. Will look into re-tuning needed timeout value (and other JSC tests timeout cleanup) in https://bugs.webkit.org/show_bug.cgi?id=205298. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): * interpreter/InterpreterInlines.h: (JSC::Interpreter::execute): * jsc.cpp: (timeoutCheckCallback): (initializeTimeoutIfNeeded): (startTimeoutThreadIfNeeded): (runJSC): (jscmain): * runtime/JSCConfig.h: * runtime/VM.h: (JSC::VM::notifyNeedShellTimeoutCheck): * runtime/VMTraps.cpp: (JSC::VMTraps::handleTraps): * runtime/VMTraps.h: (JSC::VMTraps::Mask::Mask): (JSC::VMTraps::Mask::allEventTypes): (JSC::VMTraps::Mask::init): (JSC::VMTraps::interruptingTraps): * tools/VMInspector.cpp: (JSC::VMInspector::forEachVM): * tools/VMInspector.h: 2019-12-16 Yusuke Suzuki [JSC] Remove ArrayBufferNeuteringWatchpointSet https://bugs.webkit.org/show_bug.cgi?id=205194 Reviewed by Saam Barati. This patch removes ArrayBufferNeuteringWatchpointSet, and instead putting InlineWatchpointSet directly into ArrayBuffer, since this is much simpler. The main reason why we are using ArrayBufferNeuteringWatchpointSet is not to increase sizeof(ArrayBuffer). But this complicates the implementation. So, not to increase sizeof(ArrayBuffer), we use PackedRefPtr in ArrayBuffer, which is RefPtr while the pointer is packed. This gives us 8 bytes which is suitable for placing InlineWatchpointSet without increasing sizeof(ArrayBuffer). We also convert Function<> in ArrayBuffer to PackedRefPtr>, and share Gigacage::free destructor by multiple ArrayBuffer. This is memory efficient since this is the common case, and we can pack this field easily. * API/JSTypedArray.cpp: (JSObjectMakeTypedArrayWithBytesNoCopy): (JSObjectMakeArrayBufferWithBytesNoCopy): * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetFoldableView): * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::primitiveGigacageDestructor): (JSC::SharedArrayBufferContents::~SharedArrayBufferContents): (JSC::ArrayBufferContents::destroy): (JSC::ArrayBufferContents::reset): (JSC::ArrayBufferContents::tryAllocate): (JSC::ArrayBufferContents::makeShared): (JSC::ArrayBufferContents::shareWith): (JSC::ArrayBuffer::createAdopted): (JSC::ArrayBuffer::transferTo): (JSC::ArrayBuffer::neuter): (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer): * runtime/ArrayBuffer.h: (JSC::ArrayBuffer::neuteringWatchpointSet): * runtime/ArrayBufferNeuteringWatchpointSet.cpp: Removed. * runtime/FileBasedFuzzerAgent.cpp: (JSC::FileBasedFuzzerAgent::getPredictionInternal): * runtime/FileBasedFuzzerAgentBase.cpp: (JSC::FileBasedFuzzerAgentBase::createLookupKey): * runtime/PredictionFileCreatingFuzzerAgent.cpp: (JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::buffer): 2019-12-14 Adrian Perez de Castro [GTK][WPE] Fix various non-unified build issues introduced since r251698 https://bugs.webkit.org/show_bug.cgi?id=204891 Reviewed by Alex Christensen. * API/JSCallbackConstructor.h: Add missing inclusion of JSObject.h * bytecompiler/BytecodeGeneratorBaseInlines.h: Add missing "#pragma once", which caused build breakage when the same unified source would result in multiple inclusions of the header. * bytecompiler/NodesCodegen.cpp: Add missing inclusion of BytecodeGeneratorBaseInlines.h * dfg/DFGDesiredIdentifiers.h: Add missing inclusion of Identifier.h * heap/IsoSubspacePerVM.cpp: Add missing inclusion of MarkedSpaceInlines.h * jit/GCAwareJITStubRoutine.h: Add missing forward declaration for CallLinkInfo. * runtime/PredictionFileCreatingFuzzerAgent.cpp: Add missing inclusion of wtf/DataLog.h * runtime/ScopedArgumentsTable.h: Add missing inclusion of VM.h * wasm/WasmCallee.cpp: Add missing inclusion of WasmCallingConvention.h * wasm/WasmLLIntTierUpCounter.h: Add missing inclusion of InstructionStream.h * wasm/WasmSlowPaths.cpp: Add missing inclusion of WasmSignatureInlines.h 2019-12-13 Yusuke Suzuki [JSC] Remove JSFixedArray, and use JSImmutableButterfly instead https://bugs.webkit.org/show_bug.cgi?id=204402 Reviewed by Mark Lam. This patch removes JSFixedArray, and use JSImmutableButterfly instead. JSFixedArray can be replaced by JSImmutableButterfly with Contiguous shape. And further, we can create an array from JSImmutableButterfly generated by Spread node in NewArrayBufferWithSpread. Currently, we are always creating contiguous JSImmutableButterfly from Spread. If it takes contiguous CoW array, we can reuse JSImmutableButterfly of the input. But if it is CoW and not contiguous shape (like, CopyOnWriteArrayWithInt32), we create a JSImmutableButterfly and copy it to this new butterfly. We can extend it to accept non-contiguous JSImmutableButterfly in the future. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecompiler/BytecodeGenerator.cpp: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSpread): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): (JSC::DFG::SpeculativeJIT::compileObjectKeys): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread): (JSC::FTL::DFG::LowerDFGToB3::compileSpread): (JSC::FTL::DFG::LowerDFGToB3::toButterfly): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): (JSC::loadVarargs): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSCast.h: * runtime/JSFixedArray.cpp: Removed. * runtime/JSFixedArray.h: Removed. * runtime/JSImmutableButterfly.h: (JSC::JSImmutableButterfly::createFromArray): (JSC::JSImmutableButterfly::offsetOfPublicLength): (JSC::JSImmutableButterfly::offsetOfVectorLength): * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-13 Saam Barati Structure should have a bloom filter of seen identifiers https://bugs.webkit.org/show_bug.cgi?id=205182 Reviewed by Yusuke Suzuki and Tadeu Zagallo. This patch adds a bloom filter of seen identifiers to Structure. This usually allows us to quickly determine if a Structure *has not* seen a particular property. Based on some logging I added in JetStream2 and Speedometer2, 70% of calls to Structure::get result in us returning invalidOffset (e.g, the property does not exist). This patch allows that path to be even faster. This bloom filter is just modeling what goes inside Structure's property table. For that reason, we don't need to consider things inside the static property table. We reason about the static property table inside JSObject's property lookup. This patch appears to be a 0.5% progression on Speedometer2. * runtime/Structure.cpp: (JSC::Structure::Structure): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::get): (JSC::Structure::add): 2019-12-13 Mark Lam Fix bad exception assertion in ExceptionHelpers.cpp's createError(). https://bugs.webkit.org/show_bug.cgi?id=205230 Reviewed by Yusuke Suzuki. The code in createError() was doing the following: String valueDescription = errorDescriptionForValue(globalObject, value); EXCEPTION_ASSERT(scope.exception() || !!valueDescription); if (!valueDescription) { scope.clearException(); return createOutOfMemoryError(globalObject); } If errorDescriptionForValue() throws an exception, then we expect the valueDescription string to be null so that we can throw an OutOfMemoryError. However, errorDescriptionForValue() can detect an imminent overflow in String length and just return a null string without throwing an exception which fails the above assertion. The fix is to simply do an explicit exception check in addition to the null string check and remove the assertion. * runtime/ExceptionHelpers.cpp: (JSC::createError): 2019-12-13 Saam Barati Add a Heap::finalize function that takes WTF::Function https://bugs.webkit.org/show_bug.cgi?id=205211 Reviewed by Geoffrey Garen. * heap/Heap.cpp: (JSC::Heap::addFinalizer): (JSC::Heap::FinalizerOwner::finalize): * heap/Heap.h: 2019-12-13 Jim Mason [GTK] WebKitGTK build hangs on g-ir-scanner https://bugs.webkit.org/show_bug.cgi?id=204715 This patch fixes the static initialization order problem introduced by Bug 204503. The patch replaces the static data members with statics that are constructed only upon first access (i.e., the 'construct on first use' idiom). Reviewed by Carlos Garcia Campos. * inspector/remote/RemoteInspector.h: * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::start): (Inspector::RemoteInspector::messageHandlers): * inspector/remote/glib/RemoteInspectorServer.cpp: (Inspector::RemoteInspectorServer::messageHandlers): (Inspector::RemoteInspectorServer::incomingConnectionCallback): * inspector/remote/glib/RemoteInspectorServer.h: 2019-12-12 Yusuke Suzuki [JSC] Puts fixed-sized cells into IsoSubspace more https://bugs.webkit.org/show_bug.cgi?id=205183 Reviewed by Saam Barati. This patch puts many of fixed-sized cells into IsoSubspace. - Exception - JSPropertyNameEnumerator - RegExp - StructureChain - MapBucket - JSMapIterator - ScopedArgumentsTable - SetBucket - JSSetIterator - JSScriptFetchParameters - JSScriptFetcher - JSSourceCode - JSTemplateObjectDescriptor * runtime/Exception.h: * runtime/HashMapImpl.h: (JSC::HashMapBucket::selectStructure): Deleted. (JSC::HashMapBucket::info): Deleted. (JSC::HashMapBucket::createStructure): Deleted. (JSC::HashMapBucket::create): Deleted. (JSC::HashMapBucket::createSentinel): Deleted. (JSC::HashMapBucket::HashMapBucket): Deleted. (JSC::HashMapBucket::setNext): Deleted. (JSC::HashMapBucket::setPrev): Deleted. (JSC::HashMapBucket::setKey): Deleted. (JSC::HashMapBucket::setValue): Deleted. (JSC::HashMapBucket::key const): Deleted. (JSC::HashMapBucket::value const): Deleted. (JSC::HashMapBucket::next const): Deleted. (JSC::HashMapBucket::prev const): Deleted. (JSC::HashMapBucket::deleted const): Deleted. (JSC::HashMapBucket::makeDeleted): Deleted. (JSC::HashMapBucket::offsetOfKey): Deleted. (JSC::HashMapBucket::offsetOfValue): Deleted. (JSC::HashMapBucket::offsetOfNext): Deleted. (JSC::HashMapBucket::extractValue): Deleted. * runtime/JSMapIterator.h: * runtime/JSPropertyNameEnumerator.h: * runtime/JSScriptFetchParameters.h: * runtime/JSScriptFetcher.h: * runtime/JSSetIterator.h: * runtime/JSSourceCode.h: * runtime/JSTemplateObjectDescriptor.h: * runtime/RegExp.h: * runtime/ScopedArgumentsTable.h: * runtime/StructureChain.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-12 Yusuke Suzuki [JSC] Wasm init-expr should reject mutable globals https://bugs.webkit.org/show_bug.cgi?id=205191 Reviewed by Mark Lam. For init-expr, expr must be a constant[1]. Constant expr, which is defined in Wasm spec, requires that, if the expr is GetGlobal, global's mutability is immutable. Previously our imported globals are always immutable, so we are using ASSERT instead of checking mutability in WasmSectionParser. But now, we have ability to import mutable globals. We should check mutability when parsing init-expr. We do not have this check previously, which leads to spec-correctness issue that we can initialize globals/elements/data-segments with snapshot values of mutable globals (this is safe, but this is not spec-compliant, and it is not reasonable semantics), while such an attempt should be rejected when compiling Wasm modules. This patch adds necessary checks. [1]: https://webassembly.github.io/spec/core/valid/instructions.html#valid-constant * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseInitExpr): 2019-12-12 Mark Lam Fix missing exception in JSValue::toWTFStringSlowCase(). https://bugs.webkit.org/show_bug.cgi?id=205176 Reviewed by Yusuke Suzuki. Also fix all the new exception check failures that fall out of change. Also replaced some ASSERTs with EXCEPTION_ASSERT so that we can run the exception check validation on a release build. * dfg/DFGOperations.cpp: * jsc.cpp: (dumpException): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncPush): * runtime/ExceptionHelpers.cpp: (JSC::createError): * runtime/JSCJSValue.cpp: (JSC::JSValue::toWTFStringSlowCase const): 2019-12-12 Yusuke Suzuki [JSC] Lock-down JSGlobalObject and derived classes in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=205108 Reviewed by Mark Lam. This patch puts JSGlobalLexicalEnvironment and JSGlobalObject (and its derived classes including JSDOMWindow etc.) in IsoSubspace. We were using `addFinalizer` feature to call destructors for these objects since they do not inherit JSDestructibleObject. But now each derived classes has its IsoSubspace. So we do not need to use finalizer feature: just setting specialized HeapCellType works. * API/JSAPIGlobalObject.h: * API/JSCallbackObject.cpp: * API/glib/JSAPIWrapperGlobalObject.cpp: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/SuperSampler.h: * heap/CellAttributes.h: * heap/FreeList.h: * heap/IsoHeapCellType.cpp: (JSC::IsoHeapCellType::IsoHeapCellType): * heap/IsoHeapCellType.h: * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::setIsFreeListed): Deleted. * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::setIsFreeListed): * jsc.cpp: (GlobalObject::create): Deleted. (GlobalObject::createStructure): Deleted. (GlobalObject::javaScriptRuntimeFlags): Deleted. (GlobalObject::finishCreation): Deleted. (GlobalObject::addFunction): Deleted. * runtime/JSGlobalLexicalEnvironment.h: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::subspaceFor): * runtime/JSSegmentedVariableObject.cpp: (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): (JSC::JSSegmentedVariableObject::finishCreation): (JSC::JSSegmentedVariableObject::destroy): Deleted. * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::subspaceFor): (JSC::JSSegmentedVariableObject::classInfo const): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * testRegExp.cpp: (GlobalObject::create): Deleted. (GlobalObject::createStructure): Deleted. (GlobalObject::finishCreation): Deleted. 2019-12-12 Mark Lam Fix missing exception check in JSON Stringifier's gap function. https://bugs.webkit.org/show_bug.cgi?id=205171 Reviewed by Yusuke Suzuki. * runtime/JSONObject.cpp: (JSC::gap): 2019-12-12 Mark Lam DFG and FTL expects String.prototype to not qualify for StringObjectUse. https://bugs.webkit.org/show_bug.cgi?id=205147 Reviewed by Saam Barati. Currently, String.prototype's JSType is StringObjectType. However, in the compiler, there are a few places that expect that the String.prototype value to not qualify as StringObjectUse. These places are: 1. SpeculatedType.cpp's speculationFromClassInfo() will speculate SpecObjectOther for the StringPrototype object. 2. DFGFixupPhase.cpp's addCheckStructureForOriginalStringObjectUse() only emits a CheckStructure against globalObject->stringObjectStructure(). It does not check against String.prototype's structure. To resolve this discrepancy, we can either do: a. change String.prototype's JSType to something else. b. fix the places in the compiler to accept String.prototype as StringObjectUse. (a) is trivial and cheap to do. (b) is doable but will result in less optimal compiled code. Since passing String.prototype as a StringObject is expected to be a rare thing in JS code, it's not worth incurring the cost for (b). In this patch, we apply (a) to fix the discrepancy. Also added a specialization case to FOR_EACH_JS_DYNAMIC_CAST_JS_TYPE_OVERLOAD for jsDynamicCast for completeness. * runtime/JSCast.h: * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/StringPrototype.h: 2019-12-12 Yusuke Suzuki [JSC] IsoHeapCellType should have destroy function member instead of specializing template function https://bugs.webkit.org/show_bug.cgi?id=205152 Reviewed by Saam Barati. We were specializing MarkedBlock::Handle::specializedSweep in 5 different ways for each IsoSubspace-ed cell. This bloats binary. Instead of specializing it with CellType, we specialize it with one functor, which invokes function pointer held by IsoHeapCellType. This requires one indirect function call per cell. But this is OK since, 1. We were using JSDestructibleObject's cell->classInfo->methodTable.destroy function call to dispatch destruction, before IsoSubspace replaces them with IsoHeapCellType-based destruction. Compared to that, the new one is still saving one pointer chasing basically (classInfo dereference, we assume cell deference is no cost since it will be done anyway). 2. We still keep JSString's destroy function inlining by using IsoInlinedHeapCellType. This is important since it is critical to performance and we had JSStringHeapCellType before we replaced it with IsoHeapCellType. But IsoInlinedHeapCellType specialization is for only one class so generated binary size is the same to the old code using JSStringHeapCellType. This saves 480KB binary-size in JavaScriptCore. And more importantly, after this patch, adding IsoSubspace will not bloat code, so we can simply put things into IsoSubspace. This patch also removes `using namespace JSC;` in global code in JavaScriptCore except for API codes, since it starts causing build failure due to unified builds: API defines JSType enum in a global scope, which is different from our JSC::JSType. If we do `using namespace JSC;` in a global scope, it can lead to ambiguity of looking up. * API/JSHeapFinalizerPrivate.cpp: (JSContextGroupAddHeapFinalizer): (JSContextGroupRemoveHeapFinalizer): * API/JSHeapFinalizerPrivate.h: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/AbstractMacroAssembler.cpp: * bindings/ScriptFunctionCall.cpp: * bindings/ScriptObject.cpp: * bindings/ScriptValue.cpp: * heap/IsoHeapCellType.cpp: Copied from Source/JavaScriptCore/assembler/AbstractMacroAssembler.cpp. (JSC::IsoHeapCellType::finishSweep): (JSC::IsoHeapCellType::destroy): * heap/IsoHeapCellType.h: * heap/IsoInlinedHeapCellType.h: Copied from Source/JavaScriptCore/heap/IsoHeapCellType.h. * heap/MutatorState.cpp: * heap/Synchronousness.cpp: * inspector/InjectedScriptHost.cpp: * inspector/InjectedScriptManager.cpp: * inspector/JSGlobalObjectConsoleClient.cpp: * inspector/JSGlobalObjectInspectorController.cpp: * inspector/JSGlobalObjectScriptDebugServer.cpp: * inspector/JSInjectedScriptHost.cpp: * inspector/JSInjectedScriptHostPrototype.cpp: * inspector/JSJavaScriptCallFrame.cpp: * inspector/JSJavaScriptCallFramePrototype.cpp: * inspector/JavaScriptCallFrame.cpp: * inspector/PerGlobalObjectWrapperWorld.cpp: * inspector/ScriptCallStackFactory.cpp: * inspector/ScriptDebugServer.cpp: * inspector/agents/InspectorHeapAgent.cpp: * inspector/agents/InspectorScriptProfilerAgent.cpp: * inspector/agents/JSGlobalObjectAuditAgent.cpp: * inspector/agents/JSGlobalObjectDebuggerAgent.cpp: * inspector/agents/JSGlobalObjectRuntimeAgent.cpp: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-11 Yusuke Suzuki [JSC] Put all API related JS cells into IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=205097 Reviewed by Mark Lam. This patch puts API related JS cells into IsoSubspace. * API/JSAPIGlobalObject.h: (JSC::JSAPIGlobalObject::create): Deleted. (JSC::JSAPIGlobalObject::createStructure): Deleted. (JSC::JSAPIGlobalObject::JSAPIGlobalObject): Deleted. * API/JSAPIValueWrapper.h: * API/JSAPIWrapperObject.h: (JSC::JSAPIWrapperObject::subspaceFor): * API/JSAPIWrapperObject.mm: (JSC::JSCallbackObject::subspaceForImpl): * API/JSCallbackConstructor.cpp: (JSC::JSCallbackConstructor::JSCallbackConstructor): * API/JSCallbackConstructor.h: * API/JSCallbackObject.cpp: (JSC::JSCallbackObject::createStructure): (JSC::JSCallbackObject::subspaceForImpl): (JSC::JSCallbackObject::subspaceForImpl): (JSC::JSCallbackObject::createStructure): Deleted. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::init): * API/JSClassRef.cpp: (OpaqueJSClass::prototype): * API/JSObjectRef.cpp: (JSObjectMake): (JSObjectGetPrivate): (JSObjectSetPrivate): (JSObjectGetPrivateProperty): (JSObjectSetPrivateProperty): (JSObjectDeletePrivateProperty): * API/JSValueRef.cpp: (JSValueIsObjectOfClass): * API/JSWeakObjectMapRefPrivate.cpp: * API/glib/JSAPIWrapperGlobalObject.cpp: (JSC::JSCallbackObject::subspaceForImpl): * API/glib/JSAPIWrapperGlobalObject.h: (JSC::JSAPIWrapperGlobalObject::subspaceFor): * API/glib/JSAPIWrapperObjectGLib.cpp: (JSC::JSCallbackObject::subspaceForImpl): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSSegmentedVariableObject.cpp: (JSC::JSSegmentedVariableObject::finishCreation): * runtime/JSSegmentedVariableObject.h: (JSC::JSSegmentedVariableObject::classInfo const): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-10 Saam Barati BytecodeDumper should print out of line jump targets https://bugs.webkit.org/show_bug.cgi?id=205091 Reviewed by Tadeu Zagallo and Yusuke Suzuki. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumperBase::dumpValue): * bytecode/CodeBlock.h: (JSC::CodeBlock::outOfLineJumpOffset): 2019-12-10 Yusuke Suzuki [JSC] Adhocly created CallLinkInfo in GetterSetterAccess should be owned by GCAwareJITStubRoutine https://bugs.webkit.org/show_bug.cgi?id=204876 Reviewed by Saam Barati. When emitting GetterSetterAccessCase code in IC, we dynamically create CallLinkInfo which is owned by GetterSetterAccessCase, and we use this pointer for GetterSetter calls (like, operationLinkCall etc.). The problem is that IC code is not destroyed so long as it is live in the stack. For example, GetterSetterAccessCase might be destroyed when the StructureStubInfo is reset, while executing the emitted code. So, the code is still pointing already-destroyed CallLinkInfo. In this patch, CallLinkInfo used for GetterSetterAccessCase code is owned by emitted code, which means, owned by MarkingGCAwareJITStubRoutine. So it is kept so long as the code is live. We use Bag to create a CallLinkInfo, and MarkingGCAwareJITStubRoutine owns it. The important question is whether we should call CallLinkInfo::visitWeak when the associated GetterSetterAccessCase is already destroyed. We do not need to call it since (1) it is just clearing CallLinkInfo, and (2) this information will not be used by anyone since associated GetterSetterAccessCase is already destroyed. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/GetterSetterAccessCase.h: (JSC::GetterSetterAccessCase::callLinkInfo const): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitDumbVirtualCall): * jit/GCAwareJITStubRoutine.cpp: (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine): (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler): (JSC::createJITStubRoutine): * jit/GCAwareJITStubRoutine.h: (JSC::GCAwareJITStubRoutine::create): (JSC::createJITStubRoutine): Deleted. * jit/Repatch.cpp: (JSC::linkSlowFor): (JSC::linkVirtualFor): 2019-12-10 Mark Lam Worklist::deleteCancelledPlansForVM() should not assume that a cancelled plan is ready for deletion. https://bugs.webkit.org/show_bug.cgi?id=205086 Reviewed by Saam Barati. Consider this race scenario: 1. The DFG thread finds a plan and started compiling, and it's holding a ref to the plan while it's compiling. 2. The GC thread discovers that we no longer need the plan and cancels it. 3. After the plan is cancelled but while the DFG thread is still compiling, the mutator thread calls Worklist::deleteCancelledPlansForVM(). Worklist::deleteCancelledPlansForVM() was assuming that by the time it is called, Worklist::m_cancelledPlansPendingDestruction will contain the last ref to the cancelled plan. However, this is an incorrect assumption, and the assertion there that asserts refCount == 1 will fail. This patch fixes Worklist::deleteCancelledPlansForVM() to append the cancelled plan back into m_cancelledPlansPendingDestruction if its refCount is not 1 (implying that the compiler thread still has a ref to it), and defer deletion of the plan to a subsequent call to deleteCancelledPlansForVM(). This patch also adds a WTFMove to Worklist::removeDeadPlans() when we append the cancelled plan to m_cancelledPlansPendingDestruction there. This saves us one unnecessary ref and deref of the plan. * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::deleteCancelledPlansForVM): (JSC::DFG::Worklist::removeDeadPlans): 2019-12-10 Saam Barati methodOfGettingAValueProfileFor should return argument value profiles even when node and operandNode are the same origin https://bugs.webkit.org/show_bug.cgi?id=205083 Reviewed by Yusuke Suzuki. Inside methodOfGettingAValueProfileFor, we only grab profiles when the child node and the parent node were from different code origins. This policy doesn't make sense when the child node is the load of an argument value. In that case, we can always just grab the argument profile. We might want to reconsider this policy in general, since it's common for a node to emit a GetLocal to grab its incoming arguments (this is frequently done in the DFG when reloading locals across basic blocks). This fixes an OSR exit compile loop inside Speedometer 2's React-Redux-TodoMVC benchmark. That benchmark would repeatedly exit inside CompareStrictEq by repeatedly speculating Object. That node would run with 95% incoming Objects, and 5% incoming strings, and because we didn't grab the argument value profile during exit, we never updated the profile with the String type information. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::methodOfGettingAValueProfileFor): 2019-12-10 Commit Queue Unreviewed, rolling out r253321. https://bugs.webkit.org/show_bug.cgi?id=205084 1% regression in RAMification (Requested by yusukesuzuki on #webkit). Reverted changeset: "[JSC] Put JSArray in IsoSubspace" https://bugs.webkit.org/show_bug.cgi?id=205049 https://trac.webkit.org/changeset/253321 2019-12-10 Tadeu Zagallo Reduce JSC's binary size https://bugs.webkit.org/show_bug.cgi?id=204549 Reviewed by Saam Barati. The Wasm interpreter landed in r251886 and significantly increased JSC's binary size. To try and offset that, here and some easy fixes that get us ~200kb back: - We were generating 2 instances of dumpBytecode, at 30kb each. I changed the generator to emit a cpp file instead, avoiding the duplication. - We had 3 instances of computeUsesForBytecodeIndex at 11kb each. I kept the work that depended on the template type in the template function and moved the massive switch into computeUsesForBytecodeIndexImpl. I also did the same for computeDefsForBytecodeIndex. - We had 8 instances of emit_compareAndJump(Slow) at 8kb (7kb for Slow) each. I kept the code that extracts the data from the bytecode in the template, but moved the bulk of the function into emit_compareAndJump(Slow)Impl. * CMakeLists.txt: * DerivedSources-output.xcfilelist: * DerivedSources.make: * Sources.txt: * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumperBase::printLocationAndOp): (JSC::BytecodeDumperBase::dumpValue): * bytecode/BytecodeDumper.h: (JSC::BytecodeDumperBase::~BytecodeDumperBase): (JSC::BytecodeDumperBase::dumpValue): (JSC::BytecodeDumperBase::BytecodeDumperBase): (JSC::BytecodeDumper::BytecodeDumper): * bytecode/BytecodeUseDef.cpp: Copied from Source/JavaScriptCore/bytecode/BytecodeUseDef.h. (JSC::computeUsesForBytecodeIndexImpl): (JSC::computeDefsForBytecodeIndexImpl): * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeIndex): (JSC::computeDefsForBytecodeIndex): * generator/DSL.rb: * generator/Opcode.rb: * generator/Options.rb: * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareAndJumpImpl): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsignedAndJumpImpl): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareUnsignedImpl): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_compareAndJumpSlowImpl): 2019-12-10 Yusuke Suzuki [JSC] Put JSArray in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=205049 Reviewed by Mark Lam. Put JSArray in IsoSubspace. * runtime/ArrayPrototype.h: * runtime/JSArray.h: (JSC::JSArray::subspaceFor): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * tools/JSDollarVM.cpp: 2019-12-09 Mark Lam Fix the x86_64 probe so that we can get a full stack trace with libunwind and lldb. https://bugs.webkit.org/show_bug.cgi?id=205050 Reviewed by Michael Saboff. Before this patch, the stack trace from inside a probe function is cut off at ctiMasmProbeTrampoline: (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef) ... frame #4: 0x0000000100824607 JavaScriptCore`WTF::Function::operator(this=0x000000010b88bd00, in=0x00007ffeefbfd400)(JSC::Probe::Context&) const at Function.h:79:35 frame #5: 0x0000000100823996 JavaScriptCore`JSC::stdFunctionCallback(context=0x00007ffeefbfd400) at MacroAssembler.cpp:53:5 frame #6: 0x000000010082701e JavaScriptCore`JSC::Probe::executeProbe(state=0x00007ffeefbfd480) at ProbeContext.cpp:51:5 frame #7: 0x000000010082614b JavaScriptCore`ctiMasmProbeTrampoline + 299 (lldb) After this patch, we'll now get the full stack trace from inside the probe function: (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef) ... frame #4: 0x0000000100826d17 JavaScriptCore`WTF::Function::operator(this=0x0000000106b878f8, in=0x00007ffeefbfd400)(JSC::Probe::Context&) const at Function.h:79:35 frame #5: 0x0000000100826106 JavaScriptCore`JSC::stdFunctionCallback(context=0x00007ffeefbfd400) at MacroAssembler.cpp:53:5 frame #6: 0x000000010082986e JavaScriptCore`JSC::Probe::executeProbe(state=0x00007ffeefbfd480) at ProbeContext.cpp:51:5 frame #7: 0x00000001008289a2 JavaScriptCore`ctiMasmProbeTrampoline + 338 frame #8: 0x0000466db28025be frame #9: 0x0000000100754ffc JavaScriptCore`llint_entry at LowLevelInterpreter.asm:994 frame #10: 0x0000000100738173 JavaScriptCore`vmEntryToJavaScript at LowLevelInterpreter64.asm:307 frame #11: 0x0000000101489307 JavaScriptCore`JSC::JITCode::execute(this=0x0000000106ba1520, vm=0x0000000106d00000, protoCallFrame=0x00007ffeefbfd9b8) at JITCodeInlines.h:38:38 frame #12: 0x0000000101488982 JavaScriptCore`JSC::Interpreter::executeProgram(this=0x0000000106bfd1f8, source=0x00007ffeefbff090, (null)=0x000000010d0e0000, thisObj=0x000000010d0e8020) at Interpreter.cpp:847:51 frame #13: 0x00000001017d1f9c JavaScriptCore`JSC::evaluate(globalObject=0x000000010d0e0000, source=0x00007ffeefbff090, thisValue=JSValue @ 0x00007ffeefbfef60, returnedException=0x00007ffeefbff0b0) at Completion.cpp:146:38 frame #14: 0x000000010005838f jsc`runWithOptions(globalObject=0x000000010d0e0000, options=0x00007ffeefbff620, success=0x00007ffeefbff48b) at jsc.cpp:2670:35 frame #15: 0x000000010002a0da jsc`jscmain(this=0x00007ffeefbff5a0, vm=0x0000000106d00000, globalObject=0x000000010d0e0000, success=0x00007ffeefbff48b)::$_6::operator()(JSC::VM&, GlobalObject*, bool&) const at jsc.cpp:3157:13 frame #16: 0x0000000100006eff jsc`int runJSC(options=0x00007ffeefbff620, isWorker=false, func=0x00007ffeefbff5a0)::$_6 const&) at jsc.cpp:3003:9 frame #17: 0x0000000100005988 jsc`jscmain(argc=10, argv=0x00007ffeefbff6c8) at jsc.cpp:3150:18 frame #18: 0x000000010000575e jsc`main(argc=10, argv=0x00007ffeefbff6c8) at jsc.cpp:2498:15 frame #19: 0x00007fff6cfc4da9 libdyld.dylib`start + 1 frame #20: 0x00007fff6cfc4da9 libdyld.dylib`start + 1 (lldb) The difference is that the x86_64 ctiMasmProbeTrampoline now uses the standard function prologue, and keeps %rbp pointing to trampoline function's semblance of a frame that libunwind can understand while it calls the probe function. * assembler/MacroAssemblerX86Common.cpp: 2019-12-09 Yusuke Suzuki [JSC] Put CustomGetterSetter and DOMAttributeGetterSetter in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=205044 Reviewed by Sam Weinig. Put CustomGetterSetter and DOMAttributeGetterSetter in IsoSubspace. * runtime/CustomGetterSetter.h: (JSC::CustomGetterSetter::subspaceFor): * runtime/DOMAttributeGetterSetter.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-09 Yusuke Suzuki [JSC] Remove NativeStdFunctionCell https://bugs.webkit.org/show_bug.cgi?id=205045 Reviewed by Sam Weinig. NativeStdFunctionCell is introduced because we were not able to make derived classes of JSFunction destructible. But now we can do that by using IsoSubspace. And we already have IsoSubspace for JSNativeStdFunction. So we do not need to have NativeStdFunctionCell cell. This patch removes it. And making JSNativeStdFunction destructible. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::makeAsyncCall): * runtime/JSNativeStdFunction.cpp: (JSC::JSNativeStdFunction::JSNativeStdFunction): (JSC::JSNativeStdFunction::visitChildren): (JSC::JSNativeStdFunction::finishCreation): (JSC::runStdFunction): (JSC::JSNativeStdFunction::create): * runtime/JSNativeStdFunction.h: * runtime/NativeStdFunctionCell.cpp: Removed. * runtime/NativeStdFunctionCell.h: Removed. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-09 Tadeu Zagallo [WebAssembly] Remove WasmValidate https://bugs.webkit.org/show_bug.cgi?id=205037 Reviewed by Saam Barati. It's currently only used when JSC_useWasmLLInt is false and it creates an additional instantiation of Wasm::FunctionParser, which adds about 100kb to the binary size. This does not introduce any behavior changes with the default options, but it means that we'll generate bytecode when calling WebAssembly.validate/new WebAssembly.Module even when the WasmLLInt is disabled. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::didReceiveFunctionData): * wasm/WasmEntryPlan.cpp: * wasm/WasmLLIntPlan.cpp: * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationResult): (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): * wasm/WasmModule.h: * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::work): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmPlan.cpp: * wasm/WasmValidate.cpp: Removed. * wasm/WasmValidate.h: Removed. 2019-12-09 Tadeu Zagallo REGRESSION(r253140): WebAssembly validation should check for unmatched else before calling addElse/addElseToUnreachable https://bugs.webkit.org/show_bug.cgi?id=205022 Reviewed by Saam Barati. When moving the validation code into the parser in r253140, I missed the validation check of whether an if block was at the top of the control stack before calling addElse/addElseToUnreachable. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::parseExpression): (JSC::Wasm::FunctionParser::parseUnreachableExpression): 2019-12-09 Mark Lam GetByIdVariant::dumpInContext() should not ref UniqueStringImpls. https://bugs.webkit.org/show_bug.cgi?id=205023 Reviewed by Saam Barati. This is because GetByIdVariant::dumpInContext() may be called from the compiler thread. GetByIdVariant::dumpInContext() inadvertently invoking the String copy constructor on an Identifier, which in turn, refs the underlying UniqueStringImpl. This results in a race against the mutator to adjust the refCount. The fix is to have GetByIdVariant::dumpInContext() print the underlying StringImpl instead of the Identifier itself. * bytecode/GetByIdVariant.cpp: (JSC::GetByIdVariant::dumpInContext const): 2019-12-08 Yousuke Kimoto [WinCairo] Refine initialization and error handling in RemoteInspectorSocket https://bugs.webkit.org/show_bug.cgi?id=204338 Reviewed by Fujii Hironori. RemoteInspectorSocket socket error handling is not enough, which should be refined to avoid error cases. * inspector/remote/socket/RemoteInspectorSocket.h: Modifed return value checks to hanlde error cases. * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: Refined check error handling. (Inspector::RemoteInspectorSocketEndpoint::createListener): * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: Ditto (Inspector::Socket::connect): (Inspector::Socket::listen): (Inspector::Socket::setup): (Inspector::Socket::isListening): (Inspector::Socket::getPort): (Inspector::Socket::preparePolling): * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Ditto (Inspector::Socket::Socket::create): (Inspector::Socket::setOpt): (Inspector::Socket::bindAndListen): (Inspector::Socket::connect): (Inspector::Socket::accept): (Inspector::Socket::createPair): (Inspector::Socket::setup): (Inspector::Socket::isListening): (Inspector::Socket::getPort): (Inspector::Socket::read): (Inspector::Socket::write): (Inspector::Socket::preparePolling): Initialized 'poll' with zero 2019-12-08 Tadeu Zagallo [WebAssembly] Fix LLIntGenerator's checkConsistency contract https://bugs.webkit.org/show_bug.cgi?id=204998 Reviewed by Mark Lam. We check the consistency of the WebAssembly parser's expression stack every time the LLIntGenerator calls push to allocate a new stack value. However, if we call push more than once (e.g. in a loop), the stack is no longer consistent, since those values have not yet been placed in the parser's expression stack, so the generator and parser's stacks are out of sync. Instead, whenever we need to push multiple values, we should first manually call checkConsistency before any pushes, and all pushes after that should be replaced with push(NoConsistencyCheck). * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::callInformationForCaller): (JSC::Wasm::LLIntGenerator::addArguments): (JSC::Wasm::LLIntGenerator::addLocal): 2019-12-07 Mark Lam Object.prototype.isPrototypeOf() should check if the passed in value is a non-object first. https://bugs.webkit.org/show_bug.cgi?id=204971 Reviewed by Saam Barati. The spec says Object.prototype.isPrototypeOf() should do checks in the following order: 1. If Type(V) is not Object, return false. 2. Let O be ? ToObject(this value). ... We were previously checking (2) before (1). This patch fixes this order. Ref: http://www.ecma-international.org/ecma-262/10.0/index.html#sec-object.prototype.isprototypeof * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncIsPrototypeOf): 2019-12-07 Saam Barati Unreviewed. Roll out r253201. It was not a progression on any benchmarks, and was 8% slower on JetStream 2 ML. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.rb: * bytecode/GetByValHistory.h: Added. (JSC::GetByValHistory::observeNonUID): (JSC::GetByValHistory::observe): (JSC::GetByValHistory::count const): (JSC::GetByValHistory::filter const): (JSC::GetByValHistory::update): * bytecode/PointerHistory.h: Removed. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetById): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * generator/DSL.rb: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/OptionsList.h: 2019-12-07 Mark Lam Remove invalid assertion in FTL's allocateJSArray(). https://bugs.webkit.org/show_bug.cgi?id=204987 Reviewed by Saam Barati. The assertion (in the compiler thread) does not take into account that the mutator may be in the process of transiting to HavingABadTime. As a result, the assertion may fail intermittently. This patch fixes this issue by removing this bad assertion. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): 2019-12-07 Mark Lam Build fix for: The compiler thread should not adjust Identifier refCounts. https://bugs.webkit.org/show_bug.cgi?id=204919 Not reviewed. * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeFor): 2019-12-07 Joonghun Park Unreviewed. Remove the build warning below since r250009. warning: comparison between signed and unsigned integer expressions [-Wsign-compare] This patch typecasts the "maybe signed" one as unsigned, which is the same what the compilers would do, but making the typecast explicit so that the warning go away. * b3/air/testair.cpp: 2019-12-07 Yusuke Suzuki [JSC] Put JSWrapperObject derived classes in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204976 Reviewed by Mark Lam. Put JSWrapperObject derived classes in IsoSubspace. 1. StringObject 2. NumberObject 3. SymbolObject 4. BigIntObject 5. BooleanObject * runtime/BigIntObject.h: * runtime/BooleanObject.h: (JSC::BooleanObject::subspaceFor): * runtime/BooleanPrototype.h: * runtime/JSWrapperObject.h: (JSC::JSWrapperObject::subspaceFor): * runtime/NumberObject.h: (JSC::NumberObject::subspaceFor): * runtime/NumberPrototype.h: * runtime/StringObject.h: (JSC::StringObject::subspaceFor): * runtime/StringPrototype.h: * runtime/SymbolObject.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-07 Devin Rousso Web Inspector: non-regex Local Overrides and Script Blackboxing shouldn't apply to scripts that just contain the URL https://bugs.webkit.org/show_bug.cgi?id=204954 Reviewed by Joseph Pecoraro. If `isRegex` is false, add `^` and `$` to the beginning and end of the search string to ensure that the search string is exactly matched, not just contained within the potentially intercepted URL. This doesn't actually change functionality because the Web Inspector frontend wouldn't replace the network response for these containing matches, as the frontend JavaScript already correctly performed this logic, and would therefore `Network.interceptContinue`. * inspector/ContentSearchUtilities.h: * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::escapeStringForRegularExpressionSource): Added. (Inspector::ContentSearchUtilities::createRegularExpressionForSearchString): Added. (Inspector::ContentSearchUtilities::searchInTextByLines): (Inspector::ContentSearchUtilities::createSearchRegexSource): Deleted. (Inspector::ContentSearchUtilities::createSearchRegex): Deleted. Rename functions for clarity. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::shouldBlackboxURL const): 2019-12-06 Zan Dobersek [GTK][WPE] Use bmalloc's memory footprint API for JSC heap growth management https://bugs.webkit.org/show_bug.cgi?id=204576 Reviewed by Saam Barati. Use the new USE(BMALLOC_MEMORY_FOOTPRINT_API) build guard to enable bmalloc-based JSC heap growth management on iOS family ports as well as additionally the Linux-based ports, if the configuration allows it (i.e. system malloc enforcement kept disabled). * heap/Heap.cpp: (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::updateAllocationLimits): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: Initialize the two member variables and fix a typo in one of them. * runtime/Options.cpp: (JSC::overrideDefaults): Also guard two default overrides with the new flag. 2019-12-06 Mark Lam The compiler thread should not adjust Identifier refCounts. https://bugs.webkit.org/show_bug.cgi?id=204919 Reviewed by Saam Barati. 1. Previously, in the compiler thread, we would get a Symbol uid via Symbol::privateName().uid(). Symbol::privateName() returns a copy of its PrivateName, which in turn results in ref'ing the underlying SymbolImpl. This results in a race between the mutator and compiler threads to adjust the SymbolImpl's refCount, which may result in corruption. This patch fixes this by adding Symbol::uid() which return the underlying SymbolImpl without ref'ing it. 2. Previously, in the compiler thread, we also create Box via its copy constructor. The original Box is instantiated in the mutator. The Box refs its internal Data, which is ThreadSafeRefCounted and shared by all Box for the same underlying Identifier. This ensures that the compiler thread does not ref the underlying Identifier. However, when the Box is destructed, it will also check if it holds the last ref to its internal Data. If so, it will destruct its Data, and the Identifier that it embeds. This results in the compiler thread trying to deref the StringImpl referenced by the Identifier in a race against the mutator. This patch fixes this by ensuring that for any Box instance used by the compiler thread, we will register another instance in the DFG::Plan m_identifiersKeptAliveForCleanUp list, and let the mutator destruct that Box later in the mutator. This ensures that the compiler thread will never see the last reference to a Box's internal Data and avoid the race. 3. This patch also fixes the DFG::Worklist code to ensure that a DFG::Plan is always destructed in the mutator, even if the Plan was cancelled. This, in turn, enables us to assert that the Plan is never destructed in the compiler thread. * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeFor): (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetByStatus.h: * debugger/Debugger.cpp: (JSC::Debugger::detach): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::~Plan): (JSC::DFG::Plan::computeCompileTimes const): (JSC::DFG::Plan::cancel): * dfg/DFGPlan.h: (JSC::DFG::Plan::unnukedVM const): (JSC::DFG::Plan::keepAliveIdentifier): (JSC::DFG::Plan::nuke): (JSC::DFG::Plan::unnuke): * dfg/DFGSafepoint.cpp: (JSC::DFG::Safepoint::cancel): * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::deleteCancelledPlansForVM): (JSC::DFG::Worklist::removeAllReadyPlansForVM): (JSC::DFG::Worklist::removeDeadPlans): (JSC::DFG::Worklist::removeNonCompilingPlansForVM): * dfg/DFGWorklist.h: * runtime/Symbol.h: 2019-12-06 Yusuke Suzuki [JSC] Put JSModuleNamespaceObject in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204973 Reviewed by Mark Lam. We found that we do not need to embed AbstractModuleRecord vector inside JSModuleNamespaceObject: we can just put it in ExportEntry. So we can make it non-variable-sized cell. Further, this patch puts it in IsoSubspace. * runtime/CellSize.h: (JSC::isDynamicallySizedType): (JSC::cellSize): * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::finishCreation): (JSC::JSModuleNamespaceObject::visitChildren): (JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon): * runtime/JSModuleNamespaceObject.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-06 Yusuke Suzuki [JSC] Put ModuleRecords in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204972 Reviewed by Mark Lam. This patch is putting JSModuleRecord and WebAssemblyModuleRecord in IsoSubspace. * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::destroy): Deleted. * runtime/AbstractModuleRecord.h: (JSC::AbstractModuleRecord::subspaceFor): * runtime/JSModuleRecord.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/js/WebAssemblyModuleRecord.h: 2019-12-06 Per Arne Vollan Unreviewed build fix. Initialize local variable. * API/tests/testapi.cpp: (TestAPI::promiseUnhandledRejection): 2019-12-06 Joonghun Park Unreviewed. Change the format string portable by using "%" PRIx64 instead of "%llx" for uint64_t argument. This patch removes the build warning below since r252978. warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘JSC::SpeculatedType {aka long unsigned int}’ [-Wformat=] * runtime/PredictionFileCreatingFuzzerAgent.cpp: (JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal): 2019-12-06 Commit Queue Unreviewed, rolling out r253218. https://bugs.webkit.org/show_bug.cgi?id=204968 Broke the build (Requested by ap on #webkit). Reverted changeset: "Remove various .order files." https://bugs.webkit.org/show_bug.cgi?id=204959 https://trac.webkit.org/changeset/253218 2019-12-06 Yusuke Suzuki [JSC] JSCallee should be in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204961 Reviewed by Mark Lam. We should put JSCallee in IsoSubspace. Currently, we are also putting JSToWasmICCallee in IsoSusbapce since it is a derived class of JSCallee, but I think we can remove this class completely. We are tracking it in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=204960 * debugger/DebuggerScope.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::execute): * runtime/JSCallee.h: (JSC::JSCallee::subspaceFor): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::globalCallee): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/js/JSToWasmICCallee.h: (JSC::JSToWasmICCallee::function): Deleted. (JSC::JSToWasmICCallee::JSToWasmICCallee): Deleted. 2019-12-06 Devin Rousso Web Inspector: add compiler UNLIKELY hints when checking if developer extras are enabled https://bugs.webkit.org/show_bug.cgi?id=204875 Reviewed by Joseph Pecoraro. Move the check for whether developer extras are enabled from the agent to the client so that when inspecting a webpage, we don't check for it twice, since `InspectorInstrumentation` already checks for it too. * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::developerExtrasEnabled const): Added. (Inspector::InspectorConsoleAgent::addMessageToConsole): (Inspector::InspectorConsoleAgent::startTiming): (Inspector::InspectorConsoleAgent::logTiming): (Inspector::InspectorConsoleAgent::stopTiming): (Inspector::InspectorConsoleAgent::takeHeapSnapshot): (Inspector::InspectorConsoleAgent::count): (Inspector::InspectorConsoleAgent::countReset): (Inspector::InspectorConsoleAgent::addConsoleMessage): * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel): (Inspector::JSGlobalObjectConsoleClient::count): (Inspector::JSGlobalObjectConsoleClient::countReset): (Inspector::JSGlobalObjectConsoleClient::profile): (Inspector::JSGlobalObjectConsoleClient::profileEnd): (Inspector::JSGlobalObjectConsoleClient::takeHeapSnapshot): (Inspector::JSGlobalObjectConsoleClient::time): (Inspector::JSGlobalObjectConsoleClient::timeLog): (Inspector::JSGlobalObjectConsoleClient::timeEnd): (Inspector::JSGlobalObjectConsoleClient::timeStamp): (Inspector::JSGlobalObjectConsoleClient::record): (Inspector::JSGlobalObjectConsoleClient::recordEnd): (Inspector::JSGlobalObjectConsoleClient::screenshot): 2019-12-06 Keith Miller Remove various .order files. https://bugs.webkit.org/show_bug.cgi?id=204959 Reviewed by Yusuke Suzuki. These files are all super out of date and likely don't do anything anymore. The signatures of the functions have changed thus the mangled name has changed. * JavaScriptCore.order: Removed. 2019-12-06 Joonghun Park Unreviewed. Revert r253207 because it causes compile error in Mac and ios build. * runtime/PredictionFileCreatingFuzzerAgent.cpp: (JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal): 2019-12-06 Joonghun Park Unreviewed. Remove build warning below since r252978. warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘JSC::SpeculatedType {aka long unsigned int}’ [-Wformat=] * runtime/PredictionFileCreatingFuzzerAgent.cpp: (JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal): 2019-12-05 Saam Barati get_by_id ICs should have a structure history used to indicate when we should skip generating an IC https://bugs.webkit.org/show_bug.cgi?id=204904 Reviewed by Yusuke Suzuki and Tadeu Zagallo. I implemented a similar policy for get_by_val for the number of unique seen identifiers. This allows us to create a heuristic to directly call the slow path when profiling information tells us if inline caching might not be profitable. This patch implements a similar policy for get_by_id where we profile the seen base value structures. If the LLInt observes enough unique structures, we omit emitting the inline cache in the upper tiers. The goal here was to try to speed up Speedometer2. Local testing showed this patch to repeatedly be 0.5% faster, but all the P values I got were insignificant. So it appears it's either neutral or slightly faster. This patch also adjusts the policy of seeing a non-identifier inside the PointerHistory data structure. Instead of increasing it to reach the limit when we see a non-identifier, we just treat each execution with a non-identifier to increment the count by 1. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.rb: * bytecode/GetByValHistory.h: Removed. * bytecode/PointerHistory.h: Copied from Source/JavaScriptCore/bytecode/GetByValHistory.h. (JSC::PointerHistory::observe): (JSC::PointerHistory::observeNull): (JSC::GetByValHistory::observeNonUID): Deleted. (JSC::GetByValHistory::observe): Deleted. (JSC::GetByValHistory::count const): Deleted. (JSC::GetByValHistory::filter const): Deleted. (JSC::GetByValHistory::update): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetById): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * generator/DSL.rb: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/OptionsList.h: 2019-12-05 Tadeu Zagallo [WebAssembly] Fix LLIntCallee's ownership https://bugs.webkit.org/show_bug.cgi?id=204929 Reviewed by Saam Barati. Currently, after the LLIntPlan finished generating bytecode, the Module takes ownership of the Vector of LLIntCallee's and passes a pointer to the Vector's storage to the CodeBlock. However, while we're tiering up, the module might be destroyed and we'll try to access the LLIntCallee after we finish compiling through the pointer held by the CodeBlock, which is now stale, since the Vector was owned by the Module. In order to fix this, we move the Vector into a reference counted wrapper class, LLIntCallees, and both the Module and the CodeBlock hold references to the wrapper. * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): * wasm/WasmCallee.h: (JSC::Wasm::LLIntCallees::create): (JSC::Wasm::LLIntCallees::at const): (JSC::Wasm::LLIntCallees::data const): (JSC::Wasm::LLIntCallees::LLIntCallees): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::create): (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmModule.cpp: (JSC::Wasm::Module::Module): (JSC::Wasm::Module::getOrCreateCodeBlock): * wasm/WasmModule.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): 2019-12-05 Tadeu Zagallo REGRESSION(r253140): Wasm::FunctionParser needs to bounds check in SetLocal/TeeLocal https://bugs.webkit.org/show_bug.cgi?id=204909 Reviewed by Keith Miller. When moving the code from WasmValidate.cpp to WasmFunctionParser.h, I missed that SetLocal and TeeLocal used to call Wasm::Validate::getLocal, which would perform the bounds check. I just added back the checks to the parser before accessing the local's type from m_locals. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::parseExpression): 2019-12-05 Tadeu Zagallo [WebAssembly] Fix bad assertion in LLIntPlan https://bugs.webkit.org/show_bug.cgi?id=204893 Reviewed by Mark Lam. Before landing r253140 I introduced an assertion in Wasm::LLIntPlan that the pointer to previously compiled callees must be non-null. However, it's perfectly valid for the pointer to be null when the module has no functions. * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::LLIntPlan): 2019-12-05 Mark Lam computeIfUsingFuzzerAgent() is called before parsing command line arguments. https://bugs.webkit.org/show_bug.cgi?id=204886 Reviewed by Saam Barati. Rolling out r253015 which introduced computeIfUsingFuzzerAgent(). * runtime/Options.cpp: (JSC::Options::initialize): (JSC::computeIfUsingFuzzerAgent): Deleted. * runtime/Options.h: (JSC::Options::isUsingFuzzerAgent): Deleted. * runtime/OptionsList.h: (JSC::OptionRange::operator bool const): Deleted. * runtime/VM.cpp: (JSC::VM::VM): 2019-12-05 Simon Fraser Fix inspector/css test assertions after r253158 https://bugs.webkit.org/show_bug.cgi?id=204924 Reviewed by Devin Rousso. Teach the inspector protocol about the ::highlight pseudoelement. * inspector/protocol/CSS.json: 2019-12-04 Yusuke Suzuki [JSC] AI should convert IsCellWithType to constant when Structure set is finite https://bugs.webkit.org/show_bug.cgi?id=204141 Reviewed by Mark Lam. We should fold IsCellWithType if Structure set is finite since we have a chance to know what JSType is. The difference from the last patch is that we have `if (!(child.m_type & ~SpecCell))` check. Even if structures meet the requirement, this structures do not guarantee that non cell types never come. We should ensure it by using proven type. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): 2019-12-04 Yusuke Suzuki [JSC] Put TypedArrays in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204867 Reviewed by Mark Lam. This patch puts TypedArrays in IsoSubspace. - JSArrayBuffer - JSDataView - JSInt8Array - JSInt16Array - JSInt32Array - JSUint8Array - JSUint8ClampedArray - JSUint16Array - JSUint32Array - JSFloat32Array - JSFloat64Array * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): * runtime/JSArrayBuffer.h: * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::subspaceFor): * runtime/JSDataView.h: * runtime/JSGenericTypedArrayView.h: * runtime/JSTypedArrays.h: * runtime/TypedArrayAdaptors.h: * runtime/VM.cpp: * runtime/VM.h: 2019-12-04 Tadeu Zagallo [WebAssembly] Validate and generate bytecode in one pass https://bugs.webkit.org/show_bug.cgi?id=204474 Reviewed by Saam Barati. Currently, we traverse the WebAssembly code twice: - a first serial pass that validates all functions - a second concurrent pass that compiles all functions. In this patch, we move the validation into the parser and update the LLIntPlan so that we no longer have the first pass. Instead, we now validate concurrently at the same time we generate bytecode. As a result, when we call WebAssembly.validate, we'll still generate bytecode for the module, but it will be thrown away. If the module is constructed with new WebAssembly.Module, we'll also eagerly generate bytecode, but in this case the bytecode is kept and shared across all instantiations of this module. This is a 1.5x speedup when compiling the ZenGarden demo. * DerivedSources.make: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::ControlData::ControlData): (JSC::Wasm::AirIRGenerator::ControlData::isIf): (JSC::Wasm::AirIRGenerator::ControlData::isTopLevel): (JSC::Wasm::AirIRGenerator::ControlData::branchTargetArity const): (JSC::Wasm::AirIRGenerator::ControlData::branchTargetType const): (JSC::Wasm::AirIRGenerator::emptyExpression): (JSC::Wasm::AirIRGenerator::emitCallPatchpoint): (JSC::Wasm::AirIRGenerator::tmpsForSignature): (JSC::Wasm::AirIRGenerator::emitPatchpoint): (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::addRefIsNull): (JSC::Wasm::AirIRGenerator::addTableGet): (JSC::Wasm::AirIRGenerator::addTableSet): (JSC::Wasm::AirIRGenerator::addTableGrow): (JSC::Wasm::AirIRGenerator::addTableFill): (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): (JSC::Wasm::AirIRGenerator::addLoop): (JSC::Wasm::AirIRGenerator::addBlock): (JSC::Wasm::AirIRGenerator::addIf): (JSC::Wasm::AirIRGenerator::addReturn): (JSC::Wasm::AirIRGenerator::addEndToUnreachable): (JSC::Wasm::AirIRGenerator::addCall): (JSC::Wasm::AirIRGenerator::addCallIndirect): (JSC::Wasm::AirIRGenerator::unify): (JSC::Wasm::dumpExpressionStack): (JSC::Wasm::AirIRGenerator::dump): (JSC::Wasm::parseAndCompileAir): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): * wasm/WasmAirIRGenerator.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::ControlData::ControlData): (JSC::Wasm::B3IRGenerator::ControlData::isIf): (JSC::Wasm::B3IRGenerator::ControlData::isTopLevel): (JSC::Wasm::B3IRGenerator::ControlData::signature const): (JSC::Wasm::B3IRGenerator::ControlData::hasNonVoidresult const): (JSC::Wasm::B3IRGenerator::ControlData::branchTargetArity const): (JSC::Wasm::B3IRGenerator::ControlData::branchTargetType const): (JSC::Wasm::B3IRGenerator::emptyExpression): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::addRefIsNull): (JSC::Wasm::B3IRGenerator::addTableGet): (JSC::Wasm::B3IRGenerator::addTableSet): (JSC::Wasm::B3IRGenerator::addTableGrow): (JSC::Wasm::B3IRGenerator::addTableFill): (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): (JSC::Wasm::B3IRGenerator::addBlock): (JSC::Wasm::B3IRGenerator::addIf): (JSC::Wasm::B3IRGenerator::addReturn): (JSC::Wasm::B3IRGenerator::endBlock): (JSC::Wasm::B3IRGenerator::addEndToUnreachable): (JSC::Wasm::dumpExpressionStack): (JSC::Wasm::B3IRGenerator::dump): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): (JSC::Wasm::BBQPlan::work): (JSC::Wasm::BBQPlan::compileFunction): (JSC::Wasm::BBQPlan::initializeCallees): (JSC::Wasm::BBQPlan::didReceiveFunctionData): * wasm/WasmBBQPlan.h: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::create): (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmEntryPlan.cpp: (JSC::Wasm::EntryPlan::EntryPlan): (JSC::Wasm::EntryPlan::parseAndValidateModule): (JSC::Wasm::EntryPlan::prepare): (JSC::Wasm::EntryPlan::compileFunctions): (JSC::Wasm::EntryPlan::complete): * wasm/WasmEntryPlan.h: * wasm/WasmFunctionParser.h: (JSC::Wasm::splitStack): (JSC::Wasm::FunctionParser::TypedExpression::TypedExpression): (JSC::Wasm::FunctionParser::TypedExpression::type const): (JSC::Wasm::FunctionParser::TypedExpression::value const): (JSC::Wasm::FunctionParser::TypedExpression::operator ExpressionType const): (JSC::Wasm::FunctionParser::TypedExpression::operator-> const): (JSC::Wasm::FunctionParser::controlStack): (JSC::Wasm::FunctionParser::validationFail const): (JSC::Wasm::FunctionParser::parse): (JSC::Wasm::FunctionParser::binaryCase): (JSC::Wasm::FunctionParser::unaryCase): (JSC::Wasm::FunctionParser::load): (JSC::Wasm::FunctionParser::store): (JSC::Wasm::FunctionParser::checkBranchTarget): (JSC::Wasm::FunctionParser::unify): (JSC::Wasm::FunctionParser::parseExpression): (JSC::Wasm::FunctionParser::parseUnreachableExpression): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::ControlType::topLevel): (JSC::Wasm::LLIntGenerator::ControlType::loop): (JSC::Wasm::LLIntGenerator::ControlType::isIf): (JSC::Wasm::LLIntGenerator::ControlType::isTopLevel): (JSC::Wasm::LLIntGenerator::ControlType::stackSize const): (JSC::Wasm::LLIntGenerator::ControlType::signature const): (JSC::Wasm::LLIntGenerator::ControlType::branchTargetArity const): (JSC::Wasm::LLIntGenerator::ControlType::branchTargetType const): (JSC::Wasm::LLIntGenerator::emptyExpression): (JSC::Wasm::LLIntGenerator::dump): (JSC::Wasm::LLIntGenerator::getDropKeepCount): (JSC::Wasm::LLIntGenerator::materializeConstantsAndLocals): (JSC::Wasm::LLIntGenerator::splitStack): (JSC::Wasm::parseAndCompileBytecode): (JSC::Wasm::LLIntGenerator::LLIntGenerator): (JSC::Wasm::LLIntGenerator::callInformationForCaller): (JSC::Wasm::LLIntGenerator::addLocal): (JSC::Wasm::LLIntGenerator::setLocal): (JSC::Wasm::LLIntGenerator::addLoop): (JSC::Wasm::LLIntGenerator::addBlock): (JSC::Wasm::LLIntGenerator::addIf): (JSC::Wasm::LLIntGenerator::addEndToUnreachable): (JSC::Wasm::LLIntGenerator::addCall): (JSC::Wasm::LLIntGenerator::addCallIndirect): * wasm/WasmLLIntGenerator.h: * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::LLIntPlan): (JSC::Wasm::LLIntPlan::compileFunction): (JSC::Wasm::LLIntPlan::didCompleteCompilation): (JSC::Wasm::LLIntPlan::work): (JSC::Wasm::LLIntPlan::didReceiveFunctionData): * wasm/WasmLLIntPlan.h: * wasm/WasmModule.cpp: (JSC::Wasm::Module::Module): (JSC::Wasm::makeValidationResult): (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: (JSC::Wasm::Module::create): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): * wasm/WasmSlowPaths.cpp: (JSC::LLInt::slow_path_wasm_throw_exception): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): * wasm/WasmThunks.h: * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::ControlData::isIf): (JSC::Wasm::Validate::ControlData::isTopLevel): (JSC::Wasm::Validate::ControlData::blockType const): (JSC::Wasm::Validate::ControlData::signature const): (JSC::Wasm::Validate::ControlData::branchTargetArity const): (JSC::Wasm::Validate::ControlData::branchTargetType const): (JSC::Wasm::Validate::emptyExpression): (JSC::Wasm::Validate::addConstant): (JSC::Wasm::Validate::Validate): (JSC::Wasm::Validate::addArguments): (JSC::Wasm::Validate::addTableGet): (JSC::Wasm::Validate::addTableSet): (JSC::Wasm::Validate::addTableSize): (JSC::Wasm::Validate::addTableGrow): (JSC::Wasm::Validate::addTableFill): (JSC::Wasm::Validate::addRefIsNull): (JSC::Wasm::Validate::addRefFunc): (JSC::Wasm::Validate::addLocal): (JSC::Wasm::Validate::getLocal): (JSC::Wasm::Validate::setLocal): (JSC::Wasm::Validate::getGlobal): (JSC::Wasm::Validate::setGlobal): (JSC::Wasm::Validate::addBlock): (JSC::Wasm::Validate::addLoop): (JSC::Wasm::Validate::addSelect): (JSC::Wasm::Validate::addIf): (JSC::Wasm::Validate::addElse): (JSC::Wasm::Validate::addElseToUnreachable): (JSC::Wasm::Validate::addReturn): (JSC::Wasm::Validate::addBranch): (JSC::Wasm::Validate::addSwitch): (JSC::Wasm::Validate::addGrowMemory): (JSC::Wasm::Validate::addCurrentMemory): (JSC::Wasm::Validate::endBlock): (JSC::Wasm::Validate::addEndToUnreachable): (JSC::Wasm::Validate::addCall): (JSC::Wasm::Validate::addCallIndirect): (JSC::Wasm::Validate::load): (JSC::Wasm::Validate::store): (JSC::Wasm::Validate::addOp): (JSC::Wasm::dumpExpressionStack): (JSC::Wasm::Validate::dump): (JSC::Wasm::validateFunction): * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): * wasm/generateWasmOpsHeader.py: (cppType): (cppMacro): (opcodeMacroizer): (opcodeWithTypesMacroizer): (opcodeWithTypesMacroizer.modifier): (memoryLoadMacroizer): (memoryLoadMacroizer.modifier): (memoryStoreMacroizer): (memoryStoreMacroizer.modifier): * wasm/generateWasmValidateInlinesHeader.py: Removed. * wasm/js/JSWebAssembly.cpp: (JSC::instantiate): (JSC::webAssemblyValidateFunc): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): 2019-12-04 Mark Lam Fix missing exception check in ArrayPrototype's fastJoin(). https://bugs.webkit.org/show_bug.cgi?id=204868 Reviewed by Saam Barati. * runtime/ArrayPrototype.cpp: (JSC::fastJoin): 2019-12-04 Mark Lam Fix a broken assertion in GetByStatus::computeForStubInfoWithoutExitSiteFeedback(). https://bugs.webkit.org/show_bug.cgi?id=204866 Reviewed by Saam Barati. The assertion wrong assumes that access.offset() cannot be invalid unless the access.type() is a Miss. However, if the AccessCase is a Custom value or accessor, the offset is always invalid. This patch fixes this assertion. * bytecode/AccessCase.h: (JSC::AccessCase::isCustom const): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): 2019-12-04 Yusuke Suzuki Unreviewed, rolling out r252416, vimeo does not work https://bugs.webkit.org/show_bug.cgi?id=204141 * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): 2019-12-04 Yusuke Suzuki [JSC] JSWebAssemblyGlobal creation should have exception check https://bugs.webkit.org/show_bug.cgi?id=204857 Reviewed by Mark Lam. Each WebAssembly cells have a path throwing an exception if WebAssembly is disabled. We lack exception checking after calling JSWebAssemblyGlobal::create in WebAssemblyModuleRecord linking phase. While exception is never thrown in this place since this happens only when WebAssembly is enabled, we should put `scope.assertNoException()` to satisfy exception verifier requirement. We also rename factory function of Wasm cells from "create" to "tryCreate" since it can fail potentially. * wasm/js/JSWebAssembly.cpp: (JSC::instantiate): * wasm/js/JSWebAssemblyGlobal.cpp: (JSC::JSWebAssemblyGlobal::tryCreate): (JSC::JSWebAssemblyGlobal::create): Deleted. * wasm/js/JSWebAssemblyGlobal.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::tryCreate): (JSC::JSWebAssemblyInstance::create): Deleted. * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::tryCreate): (JSC::JSWebAssemblyMemory::create): Deleted. * wasm/js/JSWebAssemblyMemory.h: * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::tryCreate): (JSC::JSWebAssemblyTable::create): Deleted. * wasm/js/JSWebAssemblyTable.h: * wasm/js/WebAssemblyGlobalConstructor.cpp: (JSC::constructJSWebAssemblyGlobal): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::constructJSWebAssemblyMemory): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::constructJSWebAssemblyTable): 2019-12-04 Yusuke Suzuki [JSC] Put more cells into IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204845 Reviewed by Saam Barati. This patch puts following cells in IsoSubspace. - ClonedArguments - JSMap - JSSet - RegExpObject * runtime/ClonedArguments.h: * runtime/JSMap.h: * runtime/JSSet.h: * runtime/RegExpObject.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/WeakMapImpl.h: (JSC::WeakMapImpl::subspaceFor): 2019-12-04 Yusuke Suzuki [JSC] Remove m_sharingMode field from JSArrayBufferPrototype and make it plain object https://bugs.webkit.org/show_bug.cgi?id=204832 Reviewed by Saam Barati. m_sharingMode field is not necessary. Just remove it and make JSArrayBufferPrototype a plain object. * runtime/JSArrayBufferPrototype.cpp: (JSC::JSArrayBufferPrototype::JSArrayBufferPrototype): (JSC::JSArrayBufferPrototype::finishCreation): (JSC::JSArrayBufferPrototype::create): * runtime/JSArrayBufferPrototype.h: 2019-12-04 Yusuke Suzuki [JSC] Place Wasm cells in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204829 Reviewed by Saam Barati. This patch places Wasm cells in IsoSubspace. We remove JSDestructibleObject inheritance in wasm cells since we can call destructor through HeapCellType's specialization. We do not need to rely on m_classInfo->methodTable->destroy. This patch does not include JSToWasmICCallee since now I'm exploring the way to remove it completely. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::destroy): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/JSWebAssemblyModule.h: * wasm/js/JSWebAssemblyTable.h: * wasm/js/WebAssemblyGlobalConstructor.h: 2019-12-04 Tim Horton Introduce a GPU process https://bugs.webkit.org/show_bug.cgi?id=204343 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: Add ENABLE(GPU_PROCESS). 2019-12-04 Yury Semikhatsky Web Inspector: allow inspector to pause provisional page load and restore its state https://bugs.webkit.org/show_bug.cgi?id=204170 Reviewed by Devin Rousso. Added an option to Target domain to pause all new targets on start waiting for explicit 'resume' command from the inspector front-end. This allows to configure inspector backend (including user agent overrides, breakpoints and instrumentation) before navigation starts. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * inspector/InspectorTarget.cpp: Added. (Inspector::InspectorTarget::pause): (Inspector::InspectorTarget::resume): (Inspector::InspectorTarget::setResumeCallback): * inspector/InspectorTarget.h: * inspector/agents/InspectorTargetAgent.cpp: (Inspector::InspectorTargetAgent::willDestroyFrontendAndBackend): (Inspector::InspectorTargetAgent::setPauseOnStart): (Inspector::InspectorTargetAgent::resume): (Inspector::buildTargetInfoObject): (Inspector::InspectorTargetAgent::targetCreated): (Inspector::InspectorTargetAgent::targetDestroyed): * inspector/agents/InspectorTargetAgent.h: * inspector/protocol/Target.json: 2019-12-03 Saam Barati Remove "patch" struct from StructureStubInfo because it adds unnecessary padding https://bugs.webkit.org/show_bug.cgi?id=204392 Reviewed by Tadeu Zagallo. By doing this, we reduce the size of StructureStubInfo from 120 bytes to 112 bytes. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/InlineAccess.cpp: (JSC::linkCodeInline): (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::getScratchRegister): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::generateArrayLength): (JSC::InlineAccess::generateStringLength): (JSC::InlineAccess::generateSelfInAccess): (JSC::InlineAccess::rewireStubAsJump): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::inlineSize const): (JSC::StructureStubInfo::patchableJump): (JSC::StructureStubInfo::valueRegs const): (JSC::StructureStubInfo::propertyRegs const): (JSC::StructureStubInfo::baseRegs const): (JSC::StructureStubInfo::baseGPR const): Deleted. (JSC::StructureStubInfo::slowPathCallLocation): Deleted. (JSC::StructureStubInfo::doneLocation): Deleted. (JSC::StructureStubInfo::slowPathStartLocation): Deleted. * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): * jit/JITInlineCacheGenerator.cpp: (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator): (JSC::JITInlineCacheGenerator::finalize): (JSC::JITByIdGenerator::JITByIdGenerator): (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): (JSC::JITPutByIdGenerator::JITPutByIdGenerator): (JSC::JITInstanceOfGenerator::JITInstanceOfGenerator): (JSC::JITGetByValGenerator::JITGetByValGenerator): * jit/Repatch.cpp: (JSC::tryCacheGetBy): (JSC::repatchGetBy): (JSC::repatchArrayGetByVal): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryCacheInByID): (JSC::repatchInByID): (JSC::repatchInstanceOf): (JSC::resetGetBy): (JSC::resetPutByID): (JSC::resetPatchableJump): (JSC::resetInByID): 2019-12-03 Yusuke Suzuki Unreviewed, fix build failure https://bugs.webkit.org/show_bug.cgi?id=186552 * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::getGlobal): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::setGlobal): 2019-12-03 Yusuke Suzuki [JSC] Remove WebAssemblyToJSCallee https://bugs.webkit.org/show_bug.cgi?id=204808 Reviewed by Tadeu Zagallo. This patch drops WebAssemblyToJSCallee. It was originally required to put small cell to retrieve VM from callee. But now this limitation is removed. We can just put JSWebAssemblyModule in callee place instead. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * interpreter/CallFrame.cpp: (JSC::CallFrame::isAnyWasmCallee): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding): * jit/Repatch.cpp: (JSC::webAssemblyOwner): (JSC::linkFor): (JSC::linkPolymorphicCall): * runtime/JSCast.h: * runtime/JSCell.cpp: * runtime/JSCellInlines.h: (JSC::isWebAssemblyModule): (JSC::isWebAssemblyToJSCallee): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const): (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const): Deleted. * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * wasm/WasmOperations.cpp: (JSC::Wasm::operationWasmToJSException): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStructure): (JSC::JSWebAssemblyModule::finishCreation): (JSC::JSWebAssemblyModule::visitChildren): (JSC::JSWebAssemblyModule::callee const): Deleted. * wasm/js/JSWebAssemblyModule.h: * wasm/js/WasmToJS.cpp: (JSC::Wasm::handleBadI64Use): (JSC::Wasm::wasmToJS): * wasm/js/WebAssemblyToJSCallee.cpp: Removed. * wasm/js/WebAssemblyToJSCallee.h: Removed. 2019-12-03 Yusuke Suzuki Adopt the new WebAssembly.Global system https://bugs.webkit.org/show_bug.cgi?id=186552 Reviewed by Keith Miller. This patch adds WebAssembly.Global implementation. It is already included in the Wasm spec (this means, it is not in staging right now: it was stage-4, and included in the spec). WebAssembly.Global is a wrapper object around "global" binding. This object can hold "immutable" and "mutable" global binding, and we can access Wasm globals through this object. Furthermore, we can share mutable global binding through this object across WebAssembly modules. To implement it efficiently, this patch introduces BindingMode to Wasm globals. If the mode is EmbeddedInInstance, we continue using the current existing mechanism. If the mode is Portable, we store a pointer to actual value in Wasm globals array in Wasm::Instance, so that we can access it through one additional dereference. And we mark all immutable globals as EmbeddedInInstance. If the binding is immutable, internally we do not need to have one binding. We can just continue using the current mechanism since users cannot observe whether immutable bindings' storage is shared or not. If the global is mutable, and it is exported outside of the module, we use Portable mode. So, all the previously used wasm global bindings are EmbeddedInInstance. Only newly added "mutable" "exported" bindings are Portable and requires one additional dereference. To access portable bindings efficiently, we add new Wasm bytecodes, `get_global_portable_binding`, `set_global_portable_binding`, and `set_global_ref_portable_binding`. This patch improves WPT wasm coverage significantly. * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/BytecodeList.rb: * heap/HeapCell.cpp: (JSC::keepAlive): (JSC::HeapCell::use const): Deleted. * heap/HeapCell.h: (JSC::keepAlive): (JSC::HeapCell::use const): * llint/WebAssembly.asm: * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::getGlobal): (JSC::Wasm::AirIRGenerator::setGlobal): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::getGlobal): (JSC::Wasm::B3IRGenerator::setGlobal): * wasm/WasmFormat.h: * wasm/WasmGlobal.cpp: Added. (JSC::Wasm::Global::get const): (JSC::Wasm::Global::set): (JSC::Wasm::Global::visitAggregate): * wasm/WasmGlobal.h: Added. * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::setGlobal): (JSC::Wasm::Instance::linkGlobal): * wasm/WasmInstance.h: (JSC::Wasm::Instance::loadI32Global const): (JSC::Wasm::Instance::loadI64Global const): (JSC::Wasm::Instance::setGlobal): (JSC::Wasm::Instance::globalsToBinding): (JSC::Wasm::Instance::getGlobalBinding): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::getGlobal): (JSC::Wasm::LLIntGenerator::setGlobal): * wasm/WasmModuleInformation.h: * wasm/WasmOperations.cpp: (JSC::Wasm::operationWasmWriteBarrierSlowPath): * wasm/WasmOperations.h: * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseImport): (JSC::Wasm::SectionParser::parseGlobal): (JSC::Wasm::SectionParser::parseExport): (JSC::Wasm::SectionParser::parseInitExpr): (JSC::Wasm::SectionParser::parseGlobalType): * wasm/WasmSectionParser.h: * wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_SLOW_PATH_DECL): * wasm/WasmSlowPaths.h: * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::setGlobal): * wasm/js/JSWebAssembly.cpp: * wasm/js/JSWebAssemblyGlobal.cpp: Added. (JSC::JSWebAssemblyGlobal::create): (JSC::JSWebAssemblyGlobal::createStructure): (JSC::JSWebAssemblyGlobal::JSWebAssemblyGlobal): (JSC::JSWebAssemblyGlobal::finishCreation): (JSC::JSWebAssemblyGlobal::destroy): (JSC::JSWebAssemblyGlobal::visitChildren): * wasm/js/JSWebAssemblyGlobal.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.h. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::visitChildren): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::destroy): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/JSWebAssemblyModule.h: * wasm/js/JSWebAssemblyTable.h: * wasm/js/WebAssemblyGlobalConstructor.cpp: Added. (JSC::constructJSWebAssemblyGlobal): (JSC::callJSWebAssemblyGlobal): (JSC::WebAssemblyGlobalConstructor::create): (JSC::WebAssemblyGlobalConstructor::createStructure): (JSC::WebAssemblyGlobalConstructor::finishCreation): (JSC::WebAssemblyGlobalConstructor::WebAssemblyGlobalConstructor): * wasm/js/WebAssemblyGlobalConstructor.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.h. * wasm/js/WebAssemblyGlobalPrototype.cpp: Added. (JSC::getGlobal): (JSC::webAssemblyGlobalProtoFuncValueOf): (JSC::webAssemblyGlobalProtoGetterFuncValue): (JSC::webAssemblyGlobalProtoSetterFuncValue): (JSC::WebAssemblyGlobalPrototype::create): (JSC::WebAssemblyGlobalPrototype::createStructure): (JSC::WebAssemblyGlobalPrototype::finishCreation): (JSC::WebAssemblyGlobalPrototype::WebAssemblyGlobalPrototype): * wasm/js/WebAssemblyGlobalPrototype.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.h. * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): 2019-12-02 Saam Barati PropertySlot should not have Customs have a PropertyOffset of zero https://bugs.webkit.org/show_bug.cgi?id=204566 Reviewed by Keith Miller. We used to say that PropertyOffset of a cacheable custom was always zero. We did this because we were using "invalidOffset" to indicate things aren't cacheable. This patch refactors PropertySlot to not look at PropertyOffset for cacheability, but instead just uses the cacheability bit. With that change, we now say that customs always have the invalid PropertyOffset. This fixes a bug where we used to watch for property changes at the offset inside an AccessCase. We were doing this for the zero property offset for all customs. This could trigger a crash inside startWatchingPropertyForReplacements because the prototype Structure was a dictionary. We allow dictionaries to be property holders of customs as long as the property is a custom and has DontDelete property attribute, since DontDelete proves the custom will never change. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/PropertySlot.h: (JSC::PropertySlot::PropertySlot): (JSC::PropertySlot::isCacheable const): (JSC::PropertySlot::setValue): (JSC::PropertySlot::setCustom): (JSC::PropertySlot::setCacheableCustom): (JSC::PropertySlot::setCustomGetterSetter): (JSC::PropertySlot::setGetterSlot): (JSC::PropertySlot::setCacheableGetterSlot): (JSC::PropertySlot::setUndefined): 2019-12-02 Yusuke Suzuki [JSC] Put some destructible objects to IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204771 Reviewed by Mark Lam. This patch puts DateInstance, ErrorInstance, and Intl objects in IsoSubspace. By using specific IsoHeapCellType, we can use JSNonFinalObject as base-classes of them instead of using JSDestructibleObject. We also introduce STATIC_ASSERT_ISO_SUBSPACE_SHARABLE to ensure that derived class of some IsoSubspace'ed one is intentional and safe. * runtime/ArrayConstructor.h: * runtime/AsyncFunctionConstructor.h: * runtime/AsyncGeneratorFunctionConstructor.h: * runtime/BigIntConstructor.h: * runtime/BooleanConstructor.h: * runtime/DateConstructor.h: * runtime/DateInstance.cpp: (JSC::DateInstance::destroy): Deleted. * runtime/DateInstance.h: * runtime/ErrorConstructor.h: * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::destroy): Deleted. * runtime/ErrorInstance.h: (JSC::ErrorInstance::destroy): (JSC::ErrorInstance::subspaceFor): * runtime/FunctionConstructor.h: * runtime/FunctionPrototype.h: * runtime/GeneratorFunctionConstructor.h: * runtime/IntlCollator.cpp: (JSC::IntlCollator::IntlCollator): (JSC::IntlCollator::destroy): Deleted. * runtime/IntlCollator.h: * runtime/IntlCollatorConstructor.h: * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::IntlDateTimeFormat): (JSC::IntlDateTimeFormat::destroy): Deleted. * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatConstructor.h: * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::IntlNumberFormat): (JSC::IntlNumberFormat::destroy): Deleted. * runtime/IntlNumberFormat.h: * runtime/IntlNumberFormatConstructor.h: * runtime/IntlPluralRules.cpp: (JSC::IntlPluralRules::IntlPluralRules): (JSC::IntlPluralRules::destroy): Deleted. * runtime/IntlPluralRules.h: * runtime/IntlPluralRulesConstructor.h: * runtime/JSArrayBufferConstructor.h: * runtime/JSCell.h: * runtime/JSObject.h: * runtime/JSTypedArrayConstructors.h: * runtime/JSTypedArrayViewConstructor.h: * runtime/MapConstructor.h: * runtime/NativeErrorConstructor.h: * runtime/NullGetterFunction.h: * runtime/NullSetterFunction.h: * runtime/NumberConstructor.h: * runtime/ObjectConstructor.h: * runtime/ProxyConstructor.h: * runtime/RegExpConstructor.h: * runtime/SetConstructor.h: * runtime/StringConstructor.h: * runtime/SymbolConstructor.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/WeakMapConstructor.h: * runtime/WeakObjectRefConstructor.h: * runtime/WeakSetConstructor.h: * tools/JSDollarVM.cpp: * wasm/js/JSWebAssemblyCompileError.h: * wasm/js/JSWebAssemblyLinkError.h: * wasm/js/JSWebAssemblyRuntimeError.h: * wasm/js/WebAssemblyCompileErrorConstructor.h: * wasm/js/WebAssemblyInstanceConstructor.h: * wasm/js/WebAssemblyLinkErrorConstructor.h: * wasm/js/WebAssemblyMemoryConstructor.h: * wasm/js/WebAssemblyModuleConstructor.h: * wasm/js/WebAssemblyRuntimeErrorConstructor.h: * wasm/js/WebAssemblyTableConstructor.h: 2019-12-02 Mark Lam Only check each use...FuzzerAgent() option in VM constructor if any of the options are enabled. https://bugs.webkit.org/show_bug.cgi?id=204763 Reviewed by Keith Miller. We know that we'll never use fuzzer agents in deployment. Hence, we shouldn't spend time checking for them in the normal use case. This probably doesn't matter much for Web processes, but for clients of JSC that repeatedly spawn and kill VMs, it might matter more. We might want to eventually widen this idiom to include other debugging / development options, but for now, I'm only covering the fuzzer agent options. * runtime/Options.cpp: (JSC::computeIfUsingFuzzerAgent): (JSC::Options::initialize): * runtime/Options.h: (JSC::Options::isUsingFuzzerAgent): * runtime/OptionsList.h: (JSC::OptionRange::operator bool const): * runtime/VM.cpp: (JSC::VM::VM): 2019-12-02 Tadeu Zagallo [JSC] Remove BytecodeCacheVersion.h https://bugs.webkit.org/show_bug.cgi?id=204760 Reviewed by Mark Lam. Having that as a phony make target causes a lot of unnecessary rebuilds. That was a workaround the fact that we only need a new cache version when we rebuild CachedTypes.cpp, but there was no straightforward way to get the current timestamp as an integer at that point. Instead, we now just use a constexpr function that hashes __TIMESTAMP__. * CMakeLists.txt: * DerivedSources-output.xcfilelist: * DerivedSources.make: * runtime/CachedTypes.cpp: (JSC::jscBytecodeCacheVersion): (JSC::GenericCacheEntry::isUpToDate const): 2019-12-02 Mark Lam mozilla-tests.yaml/js1_5/Array/regress-101964.js is frequently failing on JSC EWS bots. https://bugs.webkit.org/show_bug.cgi?id=200789 Reviewed by Keith Miller. * tools/JSDollarVM.cpp: (JSC::functionCurrentCPUTime): (JSC::JSDollarVM::finishCreation): 2019-12-02 Yusuke Suzuki [JSC] Put JSGenerator, JSAsyncGenerator, and JSPromise in IsoSubspace https://bugs.webkit.org/show_bug.cgi?id=204764 Reviewed by Mark Lam. Put more things in IsoSubspace. They are defined by using JSInternalObjectImpl mechanism. - JSGenerator - JSAsyncGenerator - JSPromise * runtime/JSAsyncGenerator.h: * runtime/JSGenerator.h: * runtime/JSPromise.h: (JSC::JSPromise::subspaceFor): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-12-01 Tuomas Karkkainen Add FuzzerAgent that reads predictions from a file https://bugs.webkit.org/show_bug.cgi?id=203898 Reviewed by Mark Lam. This patch adds a FuzzerAgent that reads predictions from a file. The predictions in the file are correlated with the prediction sites using the name of the JavaScript source file, the opcode, and start and end offsets in the source. There is also a separate FuzzerAgent that can be used to create the prediction files. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * runtime/FileBasedFuzzerAgent.cpp: Added. * runtime/FileBasedFuzzerAgent.h: Copied from Source/JavaScriptCore/runtime/RandomizingFuzzerAgent.cpp. * runtime/FileBasedFuzzerAgentBase.cpp: Added. * runtime/FileBasedFuzzerAgentBase.h: Copied from Source/JavaScriptCore/runtime/RandomizingFuzzerAgent.cpp. * runtime/FuzzerPredictions.cpp: Added. * runtime/FuzzerPredictions.h: Copied from Source/JavaScriptCore/runtime/RandomizingFuzzerAgent.cpp. * runtime/Options.cpp: * runtime/OptionsList.h: * runtime/PredictionFileCreatingFuzzerAgent.cpp: Copied from Source/JavaScriptCore/runtime/RandomizingFuzzerAgent.cpp. * runtime/PredictionFileCreatingFuzzerAgent.h: Copied from Source/JavaScriptCore/runtime/RandomizingFuzzerAgent.cpp. * runtime/RandomizingFuzzerAgent.cpp: * runtime/VM.cpp: 2019-12-01 Caio Lima [JSC][MIPS] CallFrame is being clobbered on InternalFunction execution https://bugs.webkit.org/show_bug.cgi?id=203739 Reviewed by Saam Barati. MIPS calling conventions requires that we have stack space reserved for 4 (16-bytes) arguments ($a0-$a3). The caller doesn't use this space, but callee can still use it in case where they need to save arguments or even reuse to another allocation. Since we were not allocationg it during `makeHostFunctionCall`, the caller frame slot was being clobberred by `callGenericTypedArrayView` execution, resulting in a corrupted call frame stack. This patch is adjusting this convention into ThunkGenerator and on `makeHostFunctionCall`. * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): * llint/LowLevelInterpreter32_64.asm: 2019-12-01 Caio Lima Implement GetByVal inline caching for 32-bit JITs https://bugs.webkit.org/show_bug.cgi?id=204082 Reviewed by Saam Barati. We are adding 32-bit support for GetByVal cases added on r252684. This requires changes on some of the IC code generated to properly support JSVALUE32_64. The major difference from JSVALUE64 is the usage of tagGPR to inspect value types and store results. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/StructureStubInfo.h: Since a generator can't have `thisGPR` and `propertyGPR` at se same time, we created a new `union` to share `thisTagGPR` and `propertyTagGPR`, matching the approach we have for `JITInlineCacheGenerator::patch.u`. (JSC::StructureStubInfo::propertyRegs const): (JSC::StructureStubInfo::baseRegs const): To simplify scratch register allocation, we added `baseRegs()` and `propertyRegs()` to `StructureStubInfo`, so we can easily retrive payload and tag GPRs for those operands, keeping them locked. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITInlineCacheGenerator.cpp: (JSC::JITByIdGenerator::JITByIdGenerator): (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): (JSC::JITInstanceOfGenerator::JITInstanceOfGenerator): (JSC::JITGetByValGenerator::JITGetByValGenerator): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): 2019-11-29 Eike Rathke Use default implementation for JSVALUE64 with GCC on unknown platform. https://bugs.webkit.org/show_bug.cgi?id=204701 Building on ppc64le and s390x failed with #error "Unknown architecture." Use the default implementation as fallback in these cases. Reviewed by Saam Barati. * heap/GCMemoryOperations.h: (JSC::gcSafeMemcpy): (JSC::gcSafeMemmove): (JSC::gcSafeZeroMemory): 2019-11-28 Fujii Hironori Remove ENABLE_KEYBOARD_CODE_ATTRIBUTE and ENABLE_KEYBOARD_KEY_ATTRIBUTE macros https://bugs.webkit.org/show_bug.cgi?id=204666 Reviewed by Ross Kirsling and Don Olmstead. * Configurations/FeatureDefines.xcconfig: 2019-11-26 Tuomas Karkkainen Attempting to enable more than one FuzzerAgent should result in an error https://bugs.webkit.org/show_bug.cgi?id=204607 Reviewed by Antti Koivisto. * runtime/VM.cpp: * runtime/VM.h: 2019-11-26 Carlos Garcia Campos [GLIB] The API lock should be held before calling JSC::createTypeError https://bugs.webkit.org/show_bug.cgi?id=204573 Reviewed by Mark Lam. We are missing it in several places. This is causing a crash in test /jsc/object after r252298. * API/glib/JSCContext.cpp: (jscContextGArrayToJSArray): (jscContextJSArrayToGArray): (jscContextGValueToJSValue): (jscContextJSValueToGValue): * API/glib/JSCValue.cpp: (jsc_value_new_array): (jscValueCallFunction): 2019-11-25 Yusuke Suzuki [JSC] InternalFunction should be non-destructible https://bugs.webkit.org/show_bug.cgi?id=204556 Reviewed by Mark Lam. InternalFunction and most of its subclasses should be non-destructible since they can be trivially destructed and don't use a destroy function. For the few subclasses that do need a destroy function, these should have different IsoSubspaces of their own. For each of these subclasses, we annotate needsDestruction = true, define a specific HeapCellType for them, and pass the HeapCellType to their IsoSubspace so that their destructors can be invoked. * API/ObjCCallbackFunction.h: * API/glib/JSCCallbackFunction.cpp: (JSC::JSCCallbackFunction::subspaceForImpl): Deleted. * API/glib/JSCCallbackFunction.h: (JSC::JSCCallbackFunction::subspaceFor): Deleted. (JSC::JSCCallbackFunction::createStructure): Deleted. (JSC::JSCCallbackFunction::functionCallback): Deleted. (JSC::JSCCallbackFunction::constructCallback): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): * runtime/InternalFunction.cpp: (JSC::InternalFunction::InternalFunction): * runtime/InternalFunction.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-11-25 Saam Barati Unreviewed. Fix 32-bit build. * bytecode/GetByValHistory.h: (JSC::GetByValHistory::observeNonUID): (JSC::GetByValHistory::observe): (JSC::GetByValHistory::count const): (JSC::GetByValHistory::filter const): 2019-11-24 Yusuke Suzuki [JSC] Introduce IsoHeapCellType https://bugs.webkit.org/show_bug.cgi?id=204555 Reviewed by Mark Lam. We introduce IsoHeapCellType, which destroys cell based on CellType information, which should be in IsoSubspace. By using this, we can avoid inheriting JSDestructibleObject. For each IsoSubspace, we know how to destroy cells if we use IsoHeapCellType without using methodTable. We start using it for, JSString, JSWeakMap, JSWeakSet, WebAssemblyFunction, and JSWebAssemblyCodeBlock. And we use JSNonFinalObject for the base of JSWeakMap and JSWeakSet, which shrinks size of them from 48 to 32. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/IsoHeapCellType.h: Renamed from Source/JavaScriptCore/wasm/js/WebAssemblyFunctionHeapCellType.h. * runtime/JSString.cpp: (JSC::JSString::destroy): Deleted. * runtime/JSString.h: (JSC::JSString::destroy): * runtime/JSStringHeapCellType.cpp: Removed. * runtime/JSStringHeapCellType.h: Removed. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/WeakMapImpl.h: * wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp: Removed. * wasm/js/JSWebAssemblyCodeBlockHeapCellType.h: Removed. * wasm/js/WebAssemblyFunctionHeapCellType.cpp: Removed. 2019-11-23 Ross Kirsling [JSC] GetSubstitution is performed incorrectly via RegExp.prototype[@@replace] https://bugs.webkit.org/show_bug.cgi?id=204490 Reviewed by Mark Lam. String.prototype.replace and RegExp.prototype[Symbol.replace] are meant to perform the same substitution of $-backreferences (called GetSubstitution in the spec: https://tc39.es/ecma262/#sec-getsubstitution). The implementation of this in StringPrototype.cpp is correct but the one in RegExpPrototype.js is not. In particular, the latter *removes* backreferences with out-of-range indices, instead of leaving them as-is. One thing that is *not* broken in either implementation and thus maintained here is the fact $10 is interpreted as $1 followed by a 0 when we have 1 <= n < 10 captures (and analogously for other invalid $nn backreferences). This behavior is consistent across all engines but currently described incorrectly in the spec; this patch thus aligns with the spec PR currently open to correct this (https://github.com/tc39/ecma262/pull/1732). * builtins/RegExpPrototype.js: (getSubstitution): Ensure that invalid backreferences remain untouched in the output string. (replace): Fix off-by-one error when populating captures list. We shouldn't be reserving a slot for the full match. 2019-11-22 Saam Barati Use LLInt profiling to rule out generating an IC for get_by_val https://bugs.webkit.org/show_bug.cgi?id=204536 Reviewed by Yusuke Suzuki. When I landed the get_by_val polymorphic inline caching patch, the prepack benchmark in JetStream2 slowed down by 10%. Through some analysis, I found out that we were slowing down because of the time we spent in the JITs actually generating inline caches. This patch skips generating an inline cache when it seems like it won't be profitable. The heuristic for doing this is simple: - If we see more than 4 identifiers in the LLInt, we won't generate an IC in the upper tiers. - If we see a non-identifier JSString in the LLInt, we won't generate an IC in the upper tiers. This patch recovers the regression on prepack. * bytecode/BytecodeList.rb: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * generator/main.rb: * heap/TinyBloomFilter.h: (JSC::TinyBloomFilter::bits const): (JSC::TinyBloomFilter::TinyBloomFilter): * jit/JIT.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Operations.h: (JSC::getByValWithIndex): * runtime/OptionsList.h: 2019-11-22 Per Arne Vollan Fix compile error in release mode https://bugs.webkit.org/show_bug.cgi?id=204534 Reviewed by Mark Lam. A compiler error is thrown in release mode when compiling FullBytecodeLiveness::getLiveness, since not all paths are returning a value. * bytecode/FullBytecodeLiveness.h: (JSC::FullBytecodeLiveness::getLiveness const): 2019-11-22 Tadeu Zagallo [WebAssembly] Improve Wasm::LLIntGenerator https://bugs.webkit.org/show_bug.cgi?id=204092 Reviewed by Saam Barati. This improves the Wasm::LLIntGenerator by: - Changing LLIntGenerator::ExpressionType from RefPtr to VirtualRegister: Instead of allocating and retaining RegisterIDs we use VirtualRegisters directly and ensure that they match the WebAssembly stack, i.e. the parser's expression stack should match the virtual registers. - Removing redundant moves when materializing constants and performing local.get: instead of creating a new temporary for each constant and local.get, we return the VirtualRegister for the constant/local slot directly. In order for this to work, we still allocate the stack slot for the temporaries, since we have to materialize them before loops and branches. - Adding a constructor to ControlType that takes the results ExpressionList as an rvalue instead of copying it - Optimizing callInformationFor, which is now split into two functions. The callee does not care about arguments, and should never allocate temporaries, and the caller case was optimized by avoiding unnecessary calls to newTemporary - Delay holding the lock in LLintPlan::compileFunction, since we do not need to hold it while compiling the js-to-wasm entrypoint * bytecode/BytecodeList.rb: * bytecompiler/Label.h: (JSC::GenericLabel::location const): (JSC::GenericLabel::unresolvedJumps const): * generator/Wasm.rb: * llint/WebAssembly.asm: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::endTopLevel): (JSC::Wasm::AirIRGenerator::didPopValueFromStack): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::endTopLevel): (JSC::Wasm::B3IRGenerator::didPopValueFromStack): * wasm/WasmFunctionCodeBlock.cpp: (JSC::Wasm::FunctionCodeBlock::addJumpTable): * wasm/WasmFunctionCodeBlock.h: * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::expressionStack): (JSC::Wasm::FunctionParser::parseBody): (JSC::Wasm::FunctionParser::parseExpression): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::ControlType::loop): (JSC::Wasm::LLIntGenerator::ControlType::topLevel): (JSC::Wasm::LLIntGenerator::ControlType::block): (JSC::Wasm::LLIntGenerator::ControlType::if_): (JSC::Wasm::LLIntGenerator::ControlType::targetArity const): (JSC::Wasm::LLIntGenerator::ControlType::stackSize const): (JSC::Wasm::LLIntGenerator::ControlType::ControlType): (JSC::Wasm::LLIntGenerator::unifyValuesWithBlock): (JSC::Wasm::LLIntGenerator::push): (JSC::Wasm::LLIntGenerator::didPopValueFromStack): (JSC::Wasm::LLIntGenerator::emptyExpression): (JSC::Wasm::LLIntGenerator::addEndToUnreachable): (JSC::Wasm::LLIntGenerator::dump): (JSC::Wasm::LLIntGenerator::virtualRegisterForWasmLocal): (JSC::Wasm::LLIntGenerator::jsNullConstant): (JSC::Wasm::LLIntGenerator::zeroConstant): (JSC::Wasm::LLIntGenerator::getDropKeepCount): (JSC::Wasm::LLIntGenerator::dropKeep): (JSC::Wasm::LLIntGenerator::walkExpressionStack): (JSC::Wasm::LLIntGenerator::checkConsistency): (JSC::Wasm::LLIntGenerator::materializeConstantsAndLocals): (JSC::Wasm::LLIntGenerator::materializeLocals): (JSC::Wasm::LLIntGenerator::ConstantMapHashTraits::constructDeletedValue): (JSC::Wasm::LLIntGenerator::ConstantMapHashTraits::isDeletedValue): (JSC::Wasm::LLIntGenerator::LLIntGenerator): (JSC::Wasm::LLIntGenerator::finalize): (JSC::Wasm::LLIntGenerator::callInformationForCaller): (JSC::Wasm::LLIntGenerator::callInformationForCallee): (JSC::Wasm::LLIntGenerator::addArguments): (JSC::Wasm::LLIntGenerator::addLocal): (JSC::Wasm::LLIntGenerator::didFinishParsingLocals): (JSC::Wasm::LLIntGenerator::addConstant): (JSC::Wasm::LLIntGenerator::getLocal): (JSC::Wasm::LLIntGenerator::setLocal): (JSC::Wasm::LLIntGenerator::getGlobal): (JSC::Wasm::LLIntGenerator::addLoop): (JSC::Wasm::LLIntGenerator::addTopLevel): (JSC::Wasm::LLIntGenerator::addBlock): (JSC::Wasm::LLIntGenerator::addIf): (JSC::Wasm::LLIntGenerator::addElse): (JSC::Wasm::LLIntGenerator::addElseToUnreachable): (JSC::Wasm::LLIntGenerator::addReturn): (JSC::Wasm::LLIntGenerator::addBranch): (JSC::Wasm::LLIntGenerator::addSwitch): (JSC::Wasm::LLIntGenerator::endBlock): (JSC::Wasm::LLIntGenerator::endTopLevel): (JSC::Wasm::LLIntGenerator::addCall): (JSC::Wasm::LLIntGenerator::addCallIndirect): (JSC::Wasm::LLIntGenerator::addRefIsNull): (JSC::Wasm::LLIntGenerator::addRefFunc): (JSC::Wasm::LLIntGenerator::addTableGet): (JSC::Wasm::LLIntGenerator::addTableSize): (JSC::Wasm::LLIntGenerator::addTableGrow): (JSC::Wasm::LLIntGenerator::addCurrentMemory): (JSC::Wasm::LLIntGenerator::addGrowMemory): (JSC::Wasm::LLIntGenerator::addSelect): (JSC::Wasm::LLIntGenerator::load): (JSC::GenericLabel::setLocation): * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::compileFunction): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::endTopLevel): (JSC::Wasm::Validate::didPopValueFromStack): 2019-11-22 Yusuke Suzuki [JSC] DFG terminal's liveness should respect caller's opcodeID https://bugs.webkit.org/show_bug.cgi?id=204317 Reviewed by Saam Barati. Let's consider the following example, which is freqneutly seen in Speedometer2/EmberJS-Debug. "use strict"; function assertImpl(cond) { if (!cond) throw new Error(); } function assert() { assertImpl.apply(undefined, arguments); } noInline(assert); When compiling `throw`, we emit a terminal node and put Phantom/PhantomLocal based on the bytecode liveness. When collecting liveness for each frame, we use the liveness information of the bytecode `op_call_varargs` in assert function. This means that op_call_varargs's uses are considered as live (like, `arguments` in this example). But it is not necessary to mark it "live": if we are in assertImpl, `arguments` is already loaded into the stack, and we no longer use `arguments` when exiting, and the execution after the exit. Marking this `arguments` live makes this `arguments` allocated in DFG, but this is wasteful. In this patch, we introduce BeforeUse and AfterUse concept into bytecode liveness information. And use AfterUse information when collecting liveness in the caller's frame in DFG. We only enable this for varargs for now since (1) applying this to the other ones is not profitable, and (2) we need to be careful to make stack arguments live to allow materialization of arguments objects. In op_call_varargs / op_tail_call_varargs / op_construct_varargs cases, uses are happen only for |callee|, |this|, and |arguments|. And these are no longer necessary after calling. We don't use liveness information in the next bytecode since it misses uses marked by exception handlers. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::computeFullLiveness): * bytecode/BytecodeLivenessAnalysis.h: (JSC::BytecodeLivenessAnalysis::graph): * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::BytecodeLivenessPropagation::stepOverInstructionDef): (JSC::BytecodeLivenessPropagation::stepOverInstructionUse): (JSC::BytecodeLivenessPropagation::stepOverInstructionUseInExceptionHandler): (JSC::BytecodeLivenessPropagation::stepOverInstruction): * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeIndex): (JSC::computeDefsForBytecodeIndex): * bytecode/FullBytecodeLiveness.h: (JSC::FullBytecodeLiveness::getLiveness const): (JSC::FullBytecodeLiveness::operandIsLive const): * bytecompiler/BytecodeGenerator.cpp: (JSC::ForInContext::finalize): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::flushForTerminalImpl): * dfg/DFGForAllKills.h: (JSC::DFG::forAllKilledOperands): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::isLiveInBytecode): * dfg/DFGGraph.h: (JSC::DFG::Graph::forAllLocalsLiveInBytecode): (JSC::DFG::Graph::appropriateLivenessCalculationPoint): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2019-11-22 Carlos Garcia Campos Unreviewed. Fix GTK/WPE debug build after r252770 Just remove the ASSERT instead, since it now always receive a newly created Ref. * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::setupConnection): 2019-11-22 Carlos Garcia Campos Unreviewed. Fix GTK/WPE debug build after r252770 * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::setupConnection): 2019-11-22 Carlos Garcia Campos [GTK][WPE] RemoteInspector: use sockets instead of DBus https://bugs.webkit.org/show_bug.cgi?id=204503 Reviewed by Žan Doberšek. It turns out DBus is event slower than expected. Using GSockets API we can simplify the code and make it a lot more efficient. This will drastically reduce the time to run WebDriver tests in the bots. * inspector/remote/RemoteInspector.h: * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::start): (Inspector::RemoteInspector::stopInternal): (Inspector::RemoteInspector::setupConnection): (Inspector::RemoteInspector::pushListingsNow): (Inspector::RemoteInspector::pushListingsSoon): (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage): (Inspector::RemoteInspector::sendMessageToRemote): * inspector/remote/glib/RemoteInspectorServer.cpp: (Inspector::RemoteInspectorServer::~RemoteInspectorServer): (Inspector::RemoteInspectorServer::start): (Inspector::RemoteInspectorServer::incomingConnectionCallback): (Inspector::RemoteInspectorServer::incomingConnection): (Inspector::RemoteInspectorServer::setTargetList): (Inspector::RemoteInspectorServer::setupInspectorClient): (Inspector::RemoteInspectorServer::setup): (Inspector::RemoteInspectorServer::close): (Inspector::RemoteInspectorServer::connectionDidClose): (Inspector::RemoteInspectorServer::sendMessageToBackend): (Inspector::RemoteInspectorServer::sendMessageToFrontend): (Inspector::RemoteInspectorServer::startAutomationSession): * inspector/remote/glib/RemoteInspectorServer.h: (Inspector::RemoteInspectorServer::isRunning const): 2019-11-22 Mark Lam Fix missing exception check in replaceUsingStringSearch(). https://bugs.webkit.org/show_bug.cgi?id=204496 Reviewed by Yusuke Suzuki. The CachedCall constructor can throw OutOfMemory or StackOverflow errors. This was caught by existing JSC stress tests when we run with a debug build. Also placate the exception check validator in $vm's functionCallWithStackSize(). * runtime/StringPrototype.cpp: (JSC::replaceUsingStringSearch): * tools/JSDollarVM.cpp: (JSC::functionCallWithStackSize): 2019-11-21 Mark Lam replaceUsingStringSearch() should not use CachedCall with host functions. https://bugs.webkit.org/show_bug.cgi?id=204494 Reviewed by Ross Kirsling. The CachedCall mechanism does not support calling hist functions. * runtime/StringPrototype.cpp: (JSC::replaceUsingStringSearch): 2019-11-21 Saam Barati GetByStatus should not say it took the slow path for multiple identifiers and should have a way to indicate if the StructureStubInfo it saw took the slow path https://bugs.webkit.org/show_bug.cgi?id=204435 Reviewed by Tadeu Zagallo. I discovered some issues with get by val ICs when re-running the microbenchmarks I wrote. I noticed that we were faster when not running with the DFG. The reason for this is that we were only emitting a get by val IC in the DFG/FTL when we observe the GetByStatus says it didn't "go to the slow path". The logic in GetByStatus for building up a variant list was wrong for ICs with multiple identifiers. We have a consistency check when building up the list to ensure that no two variants have structure sets which overlap, because we wouldn't know which one to choose. However, we were accidentally saying two GetByIdVariants overlap when they had different identifiers. This patch fixes that bug by also doing an identifier comparison check. Two GetByIdVariants with different identifiers do not overlap. We also used to say a GetByStatus "goes to the slow path" if any of the cases were an array-like load. I wrote that code thinking that ArrayProfile would just handle it. However, sometimes we have a get by val IC that both has string properties and int32 properties. In these kinds of scenarios, an IC is super profitable. This patch now distinguishes between a GetByStatus saying "we're a slow path" and if we actually observed the StructureStubInfo go to the slow path. In the DFG/FTL, we only forgo emitting a get by val IC when observing a prior StructureStubInfo that went to the slow path. I also realized are call to StructureStubInfo::considerCaching was wrong for get by val ICs. We were only considering the Structure in isolation, not the { Structure, Identifier } pair. For get by val, we need to consider the pair together, since {s1, "a"} and {s1, "b"} will be two different access cases. This patch demonstrates that on these microbenchmarks, get by val ICs can be between 50-200% faster. * bytecode/GetByIdVariant.cpp: (JSC::GetByIdVariant::dumpInContext const): * bytecode/GetByIdVariant.h: (JSC::GetByIdVariant::overlaps): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::GetByStatus): (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::GetByStatus::makesCalls const): (JSC::GetByStatus::slowVersion const): (JSC::GetByStatus::merge): (JSC::GetByStatus::dump const): * bytecode/GetByStatus.h: (JSC::GetByStatus::GetByStatus): (JSC::GetByStatus::takesSlowPath const): (JSC::GetByStatus::observedStructureStubInfoSlowPath const): * bytecode/ICStatusUtils.h: (JSC::appendICStatusVariant): * bytecode/InByIdVariant.h: (JSC::InByIdVariant::overlaps): * bytecode/InstanceOfVariant.h: (JSC::InstanceOfVariant::overlaps): * bytecode/PutByIdVariant.h: (JSC::PutByIdVariant::overlaps): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::visitWeakReferences): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITOperations.cpp: 2019-11-21 Mark Lam Fix broken String.prototype.replace() and replaceAll(). https://bugs.webkit.org/show_bug.cgi?id=204479 Reviewed by Ross Kirsling and Yusuke Suzuki. String.prototype.replace() regressed due to r252683: for webkit.org/b/202471. The patch failed to handle InternalFunctions. This patch also fixed a spec compliance bug for String.prototype.replace() i.e. the replaceValue needs to be evaluated before we check if there's a match in the source string. Ref: 21.1.3.16-6 at https://www.ecma-international.org/ecma-262/10.0/#sec-string.prototype.replace For String.prototype.replaceAll(), make sure it "behaves just like String.prototype.replace if searchValue is a global regular expression". Ref: https://github.com/tc39/proposal-string-replaceall r252683 also made replaceUsingStringSearch() work the same way as replaceUsingRegExpSearch(). I think this is the wrong trade off to make. replaceUsingRegExpSearch() expects each search leg to do a RegExp search, which is inherently expensive. We shouldn't make string searches slower just because the RegExp search does it that way. However, at https://bugs.webkit.org/show_bug.cgi?id=202471#c22, Ross pointed out that JetStream 2 results appeared to be neutral. I think we should double check with a micro-benchmark as well. I'll leave this for a later patch. For now, the goal of this patch is simply to achieve correctness. Ref: https://bugs.webkit.org/show_bug.cgi?id=204481 * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): (JSC::replaceUsingStringSearch): 2019-11-21 Per Arne Vollan Fix Win64 compile errors https://bugs.webkit.org/show_bug.cgi?id=204471 Reviewed by Brent Fulgham. Fix warnings being treated as errors. * bytecode/AccessCase.cpp: (JSC::AccessCase::requiresIdentifierNameMatch const): (JSC::AccessCase::requiresInt32PropertyCheck const): (JSC::AccessCase::needsScratchFPR const): (JSC::AccessCase::doesCalls const): (JSC::AccessCase::canReplace const): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): * jit/JITOperations.cpp: (JSC::profiledAdd): * jit/Repatch.cpp: (JSC::appropriateOptimizingGetByFunction): (JSC::appropriateGetByFunction): * tools/JSDollarVM.cpp: (JSC::functionCallWithStackSize): 2019-11-21 Yusuke Suzuki Unreviewed, rolling in again, regression is not caused by it https://bugs.webkit.org/show_bug.cgi?id=202471 * builtins/BuiltinNames.h: * builtins/StringPrototype.js: (replaceAll): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::jsSpliceSubstringsWithSeparators): (JSC::replaceUsingStringSearch): (JSC::replace): (JSC::stringProtoFuncReplaceUsingStringSearch): (JSC::stringProtoFuncReplaceAllUsingStringSearch): 2019-11-21 Commit Queue Unreviewed, rolling out r252683 and r252721. https://bugs.webkit.org/show_bug.cgi?id=204475 13% regression in JetStream2/prepack-wtb (Requested by yusukesuzuki on #webkit). Reverted changesets: "Implement String.prototype.replaceAll" https://bugs.webkit.org/show_bug.cgi?id=202471 https://trac.webkit.org/changeset/252683 "Unreviewed, address Darin's feedback on r252683." https://trac.webkit.org/changeset/252721 2019-11-21 Devin Rousso Web Inspector: removing the blackbox for a specific script doesn't actually remove the blackbox https://bugs.webkit.org/show_bug.cgi?id=204428 Reviewed by Timothy Hatcher. Previously, when updating the blackbox state of each existing script, we would only tell the `Debugger` about when scripts should be blackboxed, not when they shouldn't. This means that when a given script is un-blackboxed, the `Debugger` would never get told about it and would therefore still defer pauses as if it was blackboxed. The solution to this is simple; update the blackboxed state of every script, not just those that should be blackboxed, and tell the `Debugger` about each. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::setShouldBlackboxURL): 2019-11-20 Yusuke Suzuki [JSC] Extend MacroAssemblerARM64::load/store for datasize = 16 https://bugs.webkit.org/show_bug.cgi?id=204442 Reviewed by Mark Lam. Our `void load16(const void* address, RegisterID dest)` and `void store16(RegisterID src, const void* address)` are not aware of the condition that passed register can be memoryTempRegister, while `MacroAssemblerARM64::{load,store}` handles it correctly, e.g. `load` invalidates `cachedMemoryTempRegister` if destination register is memoryTempRegister. As a result, when we are emitting `or16(TrustedImm32 imm, AbsoluteAddress address)` with address where the address's value does not fit in imm, the generated code is reusing memoryTempRegister incorrectly. 0xedf8d4fb4: mov x17, #0x7af0 0xedf8d4fb8: movk x17, #0xd5a, lsl #16 0xedf8d4fbc: movk x17, #0x1, lsl #32 // Construct imm register on x17. 0xedf8d4fc0: ldrh w17, [x17] // Load half word from x17 to w17 (we should invalidate x17 memoryTempRegister here). 0xedf8d4fc4: mov w16, #0x1b 0xedf8d4fc8: orr w16, w17, w16 0xedf8d4fcc: strh w16, [x17] // x17 memoryTempRegister is reused while its content is invalid. The problem is that `load` and `store` functions are not supporting datasize = 16 case. This patch extends `MacroAssemblerARM64::{load,store}` to support 16 so that `or16` implementation looks is similar to `or32` etc. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load16): (JSC::MacroAssemblerARM64::store16): (JSC::MacroAssemblerARM64::load): (JSC::MacroAssemblerARM64::store): * assembler/testmasm.cpp: (JSC::testOrImmMem): 2019-11-20 Saam Barati Baseline JIT should fill in StructureStubInfo's propertyIsInt32 and the slow path should update the array profile more frequently https://bugs.webkit.org/show_bug.cgi?id=204432 Reviewed by Tadeu Zagallo. When I added inline caching for get by val, I removed code which updated the ArrayProfile with some frequency. This patch adds code that does that back, which recovers some of the JetStream2 regressions we are seeing. * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): 2019-11-20 Ross Kirsling Unreviewed, address Darin's feedback on r252683. * runtime/StringPrototype.cpp: (JSC::replaceUsingStringSearch): (JSC::replace): (JSC::stringProtoFuncReplaceUsingStringSearch): (JSC::stringProtoFuncReplaceAllUsingStringSearch): 2019-11-20 Caio Lima [JSC] OSR exit to LLInt is broken on MIPS https://bugs.webkit.org/show_bug.cgi?id=203737 Reviewed by Yusuke Suzuki. This patch is adjusting the OSR to LLInt mechanism to MIPS. When we use PIC on this architecture, we need to properly configure `$gp` at some places to be able to access global variables. This is required on LLInt to access Global Offset Table (got). According to MIPS ABI, the `$gp` can be recalculated during function prologue using caller register `$t9`. We also emit such instructions (we can see this as `OFFLINE_ASM_CPLOAD` macro) immediately after a non-local label on LLInt. With the introduction of OSR to LLInt mechanism, we now have return location labels that are reached from `ret` LLInt instructions. Such return locations are used to properly return to LLInt execution whenever an OSR exits from inlined call on DFG or FTL to LLInt. When OSR is materializing LLInt stack frames for inlined functions (or accessors), it sets return address to its return location label. This means that for such labels, we need to adjust `$gp` using `$ra` instead of `$t9`, given that LLInt `ret` operation uses `jr $ra` to jump the execution to there. To implement this, we changed `mipsAddPICCode` to emit code using the correct register required to recalculate `$gp`. We also changed `callTargetFunction` to use the stubs as return location points, since the declaration of global labels will emmit `OFFLINE_ASM_CPLOAD($ra)` and we don't want to execute it during normal LLInt execution. * llint/LowLevelInterpreter.asm: * offlineasm/mips.rb: 2019-11-20 Robin Morisset Fix load<16> on ARM64 https://bugs.webkit.org/show_bug.cgi?id=204326 Reviewed by Mark Lam. On ARM64 I used load<16> in https://bugs.webkit.org/show_bug.cgi?id=202832. Unfortunately it turns out to call ldr<16>, and ldr asserts that n is either 32 or 64. This fix simply calls ldrh/strh directly. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load16): (JSC::MacroAssemblerARM64::store16): 2019-11-20 Mark Lam Flaky JSC test: stress/stack-overflow-in-yarr-byteCompile.js.dfg-eager. https://bugs.webkit.org/show_bug.cgi?id=204405 Reviewed by Alexey Proskuryakov. $vm.allWithStackSize() manipulates the stack in ways that will freak out ASan. So, add SUPPRESS_ASAN to functionCallWithStackSize() to tell ASan to ignore it. * tools/JSDollarVM.cpp: 2019-11-20 Caio Lima Regression (r252680): JSCOnly build broken: no matching function for call to JSC::DFG::SpeculativeJIT::jsValueResult https://bugs.webkit.org/show_bug.cgi?id=204404 Reviewed by Saam Barati. Adjusting build after changes from r252684 and r252680. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIncOrDec): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_numeric): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): 2019-11-19 Saam Barati GetByVal should use polymorphic access and hook into a status object https://bugs.webkit.org/show_bug.cgi?id=202767 Reviewed by Keith Miller. This patch puts get_by_val in our normal IC caching infrastructure. This means building it on top of StructureStubInfo and PolymorphicAccess. For this to work, AccessCase now supports all the array load variants that we used to have fast paths for. For identifier based variants, it we just fall back to the code we've already implemented, but only after doing a runtime check that the identifier matches the expected identifier. This allows us to reuse all the IC infrastructure we have for get_by_id. Our compilation strategy is that the baseline JIT always emits a get_by_val IC. If that IC goes to the slow path, the DFG/FTL won't also emit the same IC, since it's probable that we're seeing a megamorphic switch over strings. This was needed to keep this patch neutral on Speedometer 2. It's likely there is room to improve this heuristic: https://bugs.webkit.org/show_bug.cgi?id=204336 This now allows us to have inline caches which contain array loads, and uses of different identifiers. They just show up as different access cases inside polymorphic access. This patch is a progression on various microbenchmarks, especially those with uses of a fixed set of multiple identifiers. It's neutral on JetStream 2 and Speedometer 2. This patch also hooks in get_by_val ICs to our ICStatus infrastructure. This is going to pave the way to allow us to eagerly throw away baseline code, since when we go for an FTL compile, we will be able to use the IC status from the prior compile without relying on baseline specific data structures. There are a few interesting tidbits in this patch that are worth highlighting. - Unlike get_by_id, when we take an IC snapshot for a get_by_val IC, we're not guaranteed the various identifiers in question will outlive the compile (get_by_id ensures this since they're in the constant pool of CodeBlock). For get_by_val, the Identifiers in question are dynamic fields of AccessCase, and AccessCase may get destroyed as we're compiling concurrently. Also, String's reference counting isn't thread safe, so we can't just ref it. Instead, we use a Box inside AccessCase. This allows us to safely ref the Box without refing the underlying String. We're not worried about the Box being destroyed while we're doing this, since we're holding a lock while taking an IC snapshot inside GetByStatus. - We no longer hold onto the actual JS symbol object in the inline cache. This is what we used to do for inlining by val infos. Instead, this patch extends the CheckStringIdent node to be able to handle symbols as well. This patch also renames CheckStringIdent to CheckIdent. This patch also renames various IC related helpers from GetById* to GetBy*, since they can both be used by get_by_val and get_by_id. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::AccessCase): (JSC::AccessCase::create): (JSC::AccessCase::fromStructureStubInfo): (JSC::AccessCase::commit): (JSC::AccessCase::guardedByStructureCheck const): (JSC::AccessCase::guardedByStructureCheckSkippingConstantIdentifierCheck const): (JSC::AccessCase::requiresIdentifierNameMatch const): (JSC::AccessCase::requiresInt32PropertyCheck const): (JSC::AccessCase::needsScratchFPR const): (JSC::AccessCase::forEachDependentCell const): (JSC::AccessCase::doesCalls const): (JSC::AccessCase::canReplace const): (JSC::AccessCase::dump const): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generate): (JSC::AccessCase::generateImpl): (JSC::AccessCase::toTypedArrayType): (JSC::AccessCase::checkConsistency): * bytecode/AccessCase.h: (JSC::AccessCase::uid const): (JSC::AccessCase::identifier const): (JSC::AccessCase::checkConsistency): (JSC::AccessCase::AccessCase): * bytecode/GetByIdStatus.cpp: Removed. * bytecode/GetByIdStatus.h: Removed. * bytecode/GetByIdVariant.cpp: (JSC::GetByIdVariant::GetByIdVariant): (JSC::GetByIdVariant::operator=): (JSC::GetByIdVariant::attemptToMerge): * bytecode/GetByIdVariant.h: (JSC::GetByIdVariant::domAttribute const): (JSC::GetByIdVariant::identifier const): * bytecode/GetByStatus.cpp: Copied from Source/JavaScriptCore/bytecode/GetByIdStatus.cpp. (JSC::GetByStatus::appendVariant): (JSC::GetByStatus::computeFromLLInt): (JSC::GetByStatus::computeFor): (JSC::GetByStatus::GetByStatus): (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::GetByStatus::makesCalls const): (JSC::GetByStatus::slowVersion const): (JSC::GetByStatus::merge): (JSC::GetByStatus::filter): (JSC::GetByStatus::markIfCheap): (JSC::GetByStatus::finalize): (JSC::GetByStatus::singleIdentifier const): (JSC::GetByStatus::dump const): (JSC::GetByIdStatus::appendVariant): Deleted. (JSC::GetByIdStatus::computeFromLLInt): Deleted. (JSC::GetByIdStatus::computeFor): Deleted. (JSC::GetByIdStatus::computeForStubInfo): Deleted. (JSC::GetByIdStatus::GetByIdStatus): Deleted. (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): Deleted. (JSC::GetByIdStatus::makesCalls const): Deleted. (JSC::GetByIdStatus::slowVersion const): Deleted. (JSC::GetByIdStatus::merge): Deleted. (JSC::GetByIdStatus::filter): Deleted. (JSC::GetByIdStatus::markIfCheap): Deleted. (JSC::GetByIdStatus::finalize): Deleted. (JSC::GetByIdStatus::dump const): Deleted. * bytecode/GetByStatus.h: Copied from Source/JavaScriptCore/bytecode/GetByIdStatus.h. (JSC::GetByStatus::GetByStatus): (JSC::GetByStatus::moduleNamespaceObject const): (JSC::GetByStatus::moduleEnvironment const): (JSC::GetByStatus::scopeOffset const): (JSC::GetByIdStatus::GetByIdStatus): Deleted. (JSC::GetByIdStatus::state const): Deleted. (JSC::GetByIdStatus::isSet const): Deleted. (JSC::GetByIdStatus::operator bool const): Deleted. (JSC::GetByIdStatus::isSimple const): Deleted. (JSC::GetByIdStatus::isCustom const): Deleted. (JSC::GetByIdStatus::isModuleNamespace const): Deleted. (JSC::GetByIdStatus::numVariants const): Deleted. (JSC::GetByIdStatus::variants const): Deleted. (JSC::GetByIdStatus::at const): Deleted. (JSC::GetByIdStatus::operator[] const): Deleted. (JSC::GetByIdStatus::takesSlowPath const): Deleted. (JSC::GetByIdStatus::wasSeenInJIT const): Deleted. (JSC::GetByIdStatus::moduleNamespaceObject const): Deleted. (JSC::GetByIdStatus::moduleEnvironment const): Deleted. (JSC::GetByIdStatus::scopeOffset const): Deleted. * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::GetterSetterAccessCase): (JSC::GetterSetterAccessCase::create): * bytecode/GetterSetterAccessCase.h: * bytecode/ICStatusMap.h: * bytecode/InByIdStatus.cpp: (JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::InlineAccess::canGenerateSelfPropertyReplace): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::isCacheableArrayLength): (JSC::InlineAccess::generateArrayLength): (JSC::InlineAccess::isCacheableStringLength): (JSC::InlineAccess::generateStringLength): (JSC::InlineAccess::generateSelfInAccess): * bytecode/InstanceOfAccessCase.cpp: (JSC::InstanceOfAccessCase::InstanceOfAccessCase): * bytecode/InstanceOfStatus.cpp: (JSC::InstanceOfStatus::computeForStubInfo): * bytecode/IntrinsicGetterAccessCase.cpp: (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase): (JSC::IntrinsicGetterAccessCase::create): * bytecode/IntrinsicGetterAccessCase.h: * bytecode/ModuleNamespaceAccessCase.cpp: (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase): (JSC::ModuleNamespaceAccessCase::create): * bytecode/ModuleNamespaceAccessCase.h: * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::addCase): (JSC::PolymorphicAccess::commit): (JSC::PolymorphicAccess::regenerate): (WTF::printInternal): * bytecode/PolymorphicAccess.h: * bytecode/ProxyableAccessCase.cpp: (JSC::ProxyableAccessCase::ProxyableAccessCase): (JSC::ProxyableAccessCase::create): * bytecode/ProxyableAccessCase.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeForStubInfo): * bytecode/RecordedStatuses.cpp: (JSC::RecordedStatuses::addGetByStatus): (JSC::RecordedStatuses::addGetByIdStatus): Deleted. * bytecode/RecordedStatuses.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::StructureStubInfo): (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::initArrayLength): (JSC::StructureStubInfo::initStringLength): (JSC::StructureStubInfo::initPutByIdReplace): (JSC::StructureStubInfo::initInByIdSelf): (JSC::StructureStubInfo::deref): (JSC::StructureStubInfo::aboutToDie): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::propagateTransitions): (JSC::StructureStubInfo::summary const): (JSC::StructureStubInfo::containsPC const): (JSC::StructureStubInfo::setCacheType): (JSC::StructureStubInfo::checkConsistency): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::getByIdSelfIdentifier): (JSC::StructureStubInfo::thisValueIsInThisGPR const): (JSC::StructureStubInfo::checkConsistency): (JSC::StructureStubInfo::cacheType const): (JSC::appropriateOptimizingGetByIdFunction): (JSC::appropriateGenericGetByIdFunction): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): (JSC::DFG::AbstractInterpreter::filterICStatus): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleDOMJITGetter): (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad): (JSC::DFG::ByteCodeParser::load): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDesiredIdentifiers.cpp: (JSC::DFG::DesiredIdentifiers::processCodeBlockIdentifiersIfNeeded): (JSC::DFG::DesiredIdentifiers::ensure): (JSC::DFG::DesiredIdentifiers::at const): (JSC::DFG::DesiredIdentifiers::reallyAdd): * dfg/DFGDesiredIdentifiers.h: * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: * dfg/DFGInPlaceAbstractState.cpp: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addGetByVal): * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::hasUidOperand): (JSC::DFG::Node::hasGetByStatus): (JSC::DFG::Node::getByStatus): (JSC::DFG::Node::hasGetByIdStatus): Deleted. (JSC::DFG::Node::getByIdStatus): Deleted. * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetById): (JSC::DFG::SpeculativeJIT::compileCheckIdent): (JSC::DFG::SpeculativeJIT::compileCheckStringIdent): Deleted. * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVarargsForwardingPhase.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCheckIdent): (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent): Deleted. * jit/ICStats.h: * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): (JSC::JIT::link): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::garbageStubInfo): (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): (JSC::JITInstanceOfGenerator::JITInstanceOfGenerator): (JSC::JITGetByValGenerator::JITGetByValGenerator): (JSC::JITGetByValGenerator::generateFastPath): (JSC::JITGetByValGenerator::finalize): * jit/JITInlineCacheGenerator.h: (JSC::JITGetByValGenerator::JITGetByValGenerator): (JSC::JITGetByValGenerator::slowPathJump const): * jit/JITInlines.h: (JSC::JIT::emitDoubleGetByVal): Deleted. (JSC::JIT::emitContiguousGetByVal): Deleted. (JSC::JIT::emitArrayStorageGetByVal): Deleted. * jit/JITOperations.cpp: (JSC::getByVal): (JSC::tryGetByValOptimize): Deleted. * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitGetByValWithCachedId): Deleted. (JSC::JIT::privateCompileGetByVal): Deleted. (JSC::JIT::privateCompileGetByValWithCachedId): Deleted. (JSC::JIT::emitDirectArgumentsGetByVal): Deleted. (JSC::JIT::emitScopedArgumentsGetByVal): Deleted. (JSC::JIT::emitIntTypedArrayGetByVal): Deleted. (JSC::JIT::emitFloatTypedArrayGetByVal): Deleted. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitGetByValWithCachedId): Deleted. * jit/Repatch.cpp: (JSC::appropriateOptimizingGetByFunction): (JSC::appropriateGetByFunction): (JSC::tryCacheGetBy): (JSC::repatchGetBy): (JSC::tryCacheArrayGetByVal): (JSC::repatchArrayGetByVal): (JSC::tryCachePutByID): (JSC::tryCacheInByID): (JSC::tryCacheInstanceOf): (JSC::resetGetBy): (JSC::appropriateOptimizingGetByIdFunction): Deleted. (JSC::appropriateGetByIdFunction): Deleted. (JSC::tryCacheGetByID): Deleted. (JSC::repatchGetByID): Deleted. (JSC::resetGetByID): Deleted. * jit/Repatch.h: * llint/LowLevelInterpreter.h: * runtime/DOMAnnotation.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContextAssumingStructure const): * runtime/Structure.h: 2019-11-19 Ross Kirsling Implement String.prototype.replaceAll https://bugs.webkit.org/show_bug.cgi?id=202471 Reviewed by Yusuke Suzuki. Implement the stage 3 proposal here: https://github.com/tc39/proposal-string-replaceall String.prototype.replaceAll is the same as String.prototype.replace, except: 1. When the first argument is a string, all instances of the search string are replaced. 2. When the first argument is a non-global regular expression, a TypeError is thrown. * builtins/BuiltinNames.h: * builtins/StringPrototype.js: (replaceAll): Added. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::jsSpliceSubstringsWithSeparators): Add early out for single-replacement case. (JSC::replaceUsingStringSearch): Add global replacement logic, following replaceUsingRegExpSearch. (JSC::replace): (JSC::stringProtoFuncReplaceUsingStringSearch): (JSC::stringProtoFuncReplaceAllUsingStringSearch): Added. 2019-11-19 Robin Morisset [ESNext][BigInt] Add support for op_inc https://bugs.webkit.org/show_bug.cgi?id=193240 Reviewed by Yusuke Suzuki. This patch adds support for both ++ and -- on BigInts. It required the following secondary changes: - teaching FixupPhase how to replace it by ArithAdd/ArithSub/ValueAdd/ValueSub when the type is Int32/Double/BigInt - pulling ObservedResults out of UnaryArithProfile/BinaryArithProfile, so that it can be used by ArithAdd regardless of whether it comes from an Inc or from an Add - adding the constant 1n to the VM object so that it can be used by FixupPhase since it cannot allocate a new JSValue. - adding an UnaryArithProfile to op_inc and op_dec, and teaching the llint to update them. - adding ToNumeric (identity on bigints, same as toNumber on everything else) to all tiers * bytecode/ArithProfile.cpp: (JSC::ArithProfile::shouldEmitSetDouble const): (JSC::ArithProfile::emitSetDouble const): (JSC::ArithProfile::shouldEmitSetNonNumeric const): (JSC::ArithProfile::shouldEmitSetBigInt const): (JSC::ArithProfile::emitSetNonNumeric const): (JSC::ArithProfile::emitSetBigInt const): * bytecode/ArithProfile.h: (JSC::ObservedResults::ObservedResults): (JSC::ObservedResults::didObserveNonInt32): (JSC::ObservedResults::didObserveDouble): (JSC::ObservedResults::didObserveNonNegZeroDouble): (JSC::ObservedResults::didObserveNegZeroDouble): (JSC::ObservedResults::didObserveNonNumeric): (JSC::ObservedResults::didObserveBigInt): (JSC::ObservedResults::didObserveInt32Overflow): (JSC::ObservedResults::didObserveInt52Overflow): (JSC::ArithProfile::observedResults const): (JSC::ArithProfile::didObserveNonInt32 const): (JSC::ArithProfile::didObserveDouble const): (JSC::ArithProfile::didObserveNonNegZeroDouble const): (JSC::ArithProfile::didObserveNegZeroDouble const): (JSC::ArithProfile::didObserveNonNumeric const): (JSC::ArithProfile::didObserveBigInt const): (JSC::ArithProfile::didObserveInt32Overflow const): (JSC::ArithProfile::didObserveInt52Overflow const): (JSC::ArithProfile::setObservedNonNegZeroDouble): (JSC::ArithProfile::setObservedNegZeroDouble): (JSC::ArithProfile::setObservedNonNumeric): (JSC::ArithProfile::setObservedBigInt): (JSC::ArithProfile::setObservedInt32Overflow): (JSC::ArithProfile::setObservedInt52Overflow): (JSC::ArithProfile::observeResult): * bytecode/BytecodeList.rb: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeIndex): (JSC::computeDefsForBytecodeIndex): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::unaryArithProfileForPC): * bytecode/ExitKind.h: * bytecode/SpeculatedType.h: (JSC::isInt32SpeculationForArithmetic): (JSC::isInt32OrBooleanSpeculationForArithmetic): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::emitToNumeric): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::emitPostIncOrDec): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupToNumeric): * dfg/DFGMayExit.cpp: * 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::compileIncOrDec): (JSC::DFG::SpeculativeJIT::compileToPrimitive): (JSC::DFG::SpeculativeJIT::compileToNumeric): * 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::compileIncOrDec): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITMathIC.h: (JSC::JITMathIC::generateInline): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateFastPath): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_to_numeric): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_numeric): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/JSBigInt.cpp: (JSC::JSBigInt::inc): (JSC::JSBigInt::dec): * runtime/JSBigInt.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-11-19 Yusuke Suzuki [JSC] MetadataTable::sizeInBytes should not touch m_rawBuffer in UnlinkedMetadataTable unless MetadataTable is linked to that UnlinkedMetadataTable https://bugs.webkit.org/show_bug.cgi?id=204390 Reviewed by Mark Lam. We have a race issue here. When calling MetadataTable::sizeInBytes, we call UnlinkedMetadataTable::sizeInBytes since we change the result based on whether this MetadataTable is linked to this UnlinkedMetadataTable or not. The problem is that we are calling `UnlinkedMetadataTable::totalSize` unconditionally in UnlinkedMetadataTable::sizeInBytes, and this is touching m_rawBuffer unconditionally. This is not correct since it is possible that this m_rawBuffer is realloced while we are calling MetadataTable::sizeInBytes in GC thread. 1. The GC thread is calling MetadataTable::sizeInBytes for MetadataTable "A". 2. The main thread is destroying MetadataTable "B". 3. MetadataTable "B" is linked to UnlinkedMetadataTable "C". 4. MetadataTable "A" is pointing to UnlinkedMetadataTable "C". 5. "A" is touching UnlinkedMetadataTable::m_rawBuffer in "C", called from MetadataTable::sizeInBytes. 6. (2) destroys MetadataTable "B", and realloc UnlinkedMetadataTable::m_rawBuffer in "C". 7. (5) can touch already freed buffer. This patch fixes UnlinkedMetadataTable::sizeInBytes: not touching m_rawBuffer unless it is owned by the caller's MetadataTable. We need to call UnlinkedMetadataTable::sizeInBytes anyway since we need to adjust the result based on whether the caller MetadataTable is linked to this UnlinkedMetadataTable. * bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::sizeInBytes): 2019-11-19 Fujii Hironori [JSC] DisallowVMReentry and DeferGC should use WTF::ThreadSpecific instead of using WTF::threadSpecificKeyCreate directly https://bugs.webkit.org/show_bug.cgi?id=204350 Reviewed by Yusuke Suzuki. WTF provides two thread specific storages, ThreadSpecific and threadSpecificKeyCreate. Only DisallowVMReentry and DeferGC were using the latter. They should use WTF::ThreadSpecific because it is a useful type-safe wrapper class. * heap/DeferGC.cpp: * heap/DeferGC.h: (JSC::DisallowGC::initialize): (JSC::DisallowGC::scopeReentryCount): (JSC::DisallowGC::setScopeReentryCount): * runtime/DisallowVMReentry.cpp: * runtime/DisallowVMReentry.h: (JSC::DisallowVMReentry::initialize): (JSC::DisallowVMReentry::scopeReentryCount): (JSC::DisallowVMReentry::setScopeReentryCount): 2019-11-19 Yusuke Suzuki [JSC] Work-around Leaks' false-positive report about memory leaking https://bugs.webkit.org/show_bug.cgi?id=204384 Reviewed by Mark Lam. According to the radar, Leaks start reporting false-positive memory leaks about ExecutableAllocator and FixedVMPoolExecutableAllocator, while they are per-process singleton and reachable through g_jscConfig. I'm guessing this is because Leaks start skipping scan for readonly memory region. (g_jscConfig is now mprotected to readonly). To work-around this, we anchor these heap allocated things to global variables to help Leaks scan. Once it is fixed, we should remove it. * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::initializeUnderlyingAllocator): (JSC::ExecutableAllocator::initialize): 2019-11-18 Mark Lam Always enable Optional parse(const char* string) for OS(DARWIN). https://bugs.webkit.org/show_bug.cgi?id=204333 Reviewed by Yusuke Suzuki. On OS(DARWIN), the compiler does not consider size_t and unsigned to be the same type, even for 32-bit targets. Hence, we need the size_t version of the function in addition to the unsigned version. * runtime/Options.cpp: (JSC::parse): 2019-11-18 Devin Rousso Web Inspector: Local Resource Overrides: allow substitution based on a url pattern https://bugs.webkit.org/show_bug.cgi?id=202375 Reviewed by Brian Burg. Often, websites will load content with a timestamp-based URL query parameter for cache-busting or logging purposes. If a developer is trying to override these resources (or is trying to have an existing override also match these resources), they'd need to edit the local override's URL to match in addition to editing the resource that loads it (e.g. change the