Google Git
Sign in
webkit / WebKit / 1d8e24db21e92418396c23d6dfd8b69759a2c509 / . / Source / JavaScriptCore / ChangeLog
blob: dd8f57e56d31cd7b52239ddbfaa10193904b31c9 [file] [log] [blame]
2019-08-18 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Add makeUnique<T>, which ensures T is fast-allocated, makeUnique / makeUniqueWithoutFastMallocCheck part
https://bugs.webkit.org/show_bug.cgi?id=200620
Reviewed by Geoff Garen.
* API/JSCallbackObject.h:
(JSC::JSCallbackObjectData::setPrivateProperty):
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::JSCallbackObject):
* API/JSClassRef.cpp:
(OpaqueJSClassContextData::OpaqueJSClassContextData):
(OpaqueJSClass::contextData):
* API/JSMarkingConstraintPrivate.cpp:
(JSContextGroupAddMarkingConstraint):
* API/JSWrapperMap.mm:
(-[JSWrapperMap initWithGlobalContextRef:]):
* API/ObjCCallbackFunction.mm:
(ArgumentTypeDelegate::typeInteger):
(ArgumentTypeDelegate::typeDouble):
(ArgumentTypeDelegate::typeBool):
(ArgumentTypeDelegate::typeId):
(ArgumentTypeDelegate::typeOfClass):
(ArgumentTypeDelegate::typeStruct):
(ResultTypeDelegate::typeInteger):
(ResultTypeDelegate::typeDouble):
(ResultTypeDelegate::typeBool):
(ResultTypeDelegate::typeVoid):
(ResultTypeDelegate::typeId):
(ResultTypeDelegate::typeOfClass):
(ResultTypeDelegate::typeBlock):
(ResultTypeDelegate::typeStruct):
(objCCallbackFunctionForInvocation):
* API/glib/JSCContext.cpp:
(jscContextSetVirtualMachine):
* API/glib/JSCWrapperMap.cpp:
(JSC::WrapperMap::WrapperMap):
* assembler/ProbeStack.cpp:
(JSC::Probe::Stack::ensurePageFor):
* b3/B3LowerToAir.cpp:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
(JSC::B3::Procedure::dominators):
(JSC::B3::Procedure::naturalLoops):
(JSC::B3::Procedure::backwardsCFG):
(JSC::B3::Procedure::backwardsDominators):
(JSC::B3::Procedure::addDataSection):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::cCallSpecial):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/testair.cpp:
* b3/testb3.h:
(compileProc):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/AccessCaseSnippetParams.cpp:
* bytecode/BytecodeBasicBlock.cpp:
(JSC::BytecodeBasicBlock::computeImpl):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::setFrameShuffleData):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::ensureJITDataSlow):
(JSC::CodeBlock::setCalleeSaveRegisters):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::createRareDataIfNecessary):
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::add):
* bytecode/DeferredCompilationCallback.cpp:
(JSC::DeferredCompilationCallback::ensureDeferredSourceDump):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::operator=):
* bytecode/LazyOperandValueProfile.cpp:
(JSC::CompressedLazyOperandValueProfileHolder::add):
* bytecode/PolyProtoAccessChain.h:
(JSC::PolyProtoAccessChain::clone):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::operator=):
* bytecode/RecordedStatuses.cpp:
(JSC::RecordedStatuses::addCallLinkStatus):
(JSC::RecordedStatuses::addGetByIdStatus):
(JSC::RecordedStatuses::addPutByIdStatus):
(JSC::RecordedStatuses::addInByIdStatus):
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::WatchpointsOnStructureStubInfo::ensureReferenceAndAddWatchpoint):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::addAccessCase):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::ensureRareDataSlow):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generate):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::AbstractInterpreter):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::livenessFor):
(JSC::DFG::Graph::killsFor):
(JSC::DFG::Graph::ensureCPSCFG):
(JSC::DFG::Graph::ensureCPSDominators):
(JSC::DFG::Graph::ensureSSADominators):
(JSC::DFG::Graph::ensureCPSNaturalLoops):
(JSC::DFG::Graph::ensureSSANaturalLoops):
(JSC::DFG::Graph::ensureBackwardsCFG):
(JSC::DFG::Graph::ensureBackwardsDominators):
(JSC::DFG::Graph::ensureControlEquivalenceAnalysis):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::addressOfDoubleConstant):
* dfg/DFGLivenessAnalysisPhase.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::slowPathCall):
(JSC::DFG::slowPathMove):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::arrayify):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::emitStructureCheck):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::createNewThread):
* disassembler/Disassembler.cpp:
(JSC::disassembleAsynchronously):
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::IndexedAbstractHeap::atSlow):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLFail.cpp:
(JSC::FTL::fail):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::allocatorForSlow):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::protectedObjectTypeCounts):
(JSC::Heap::objectTypeCounts):
(JSC::Heap::addCoreConstraints):
* heap/HeapInlines.h:
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::buildSnapshot):
* heap/IsoCellSet.cpp:
(JSC::IsoCellSet::addSlow):
* heap/IsoSubspace.cpp:
(JSC::IsoSubspace::IsoSubspace):
* heap/MarkingConstraintSet.cpp:
(JSC::MarkingConstraintSet::add):
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
(Inspector::JSGlobalObjectConsoleClient::profile):
(Inspector::JSGlobalObjectConsoleClient::profileEnd):
(Inspector::JSGlobalObjectConsoleClient::warnUnimplemented):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
(Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent):
(Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent):
(Inspector::JSGlobalObjectInspectorController::createLazyAgents):
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::InspectorAgent):
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
(Inspector::InspectorConsoleAgent::startTiming):
(Inspector::InspectorConsoleAgent::logTiming):
(Inspector::InspectorConsoleAgent::stopTiming):
(Inspector::InspectorConsoleAgent::count):
(Inspector::InspectorConsoleAgent::countReset):
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::InspectorHeapAgent):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::InspectorScriptProfilerAgent):
* inspector/agents/InspectorTargetAgent.cpp:
(Inspector::InspectorTargetAgent::InspectorTargetAgent):
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
(Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
(Inspector::JSGlobalObjectRuntimeAgent::JSGlobalObjectRuntimeAgent):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::createClient):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
* jit/JITThunks.cpp:
(JSC::JITThunks::JITThunks):
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* jsc.cpp:
(runJSC):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
* parser/Parser.h:
(JSC::Scope::pushLabel):
(JSC::Parser<LexerType>::parse):
* parser/ParserArena.h:
(JSC::ParserArena::identifierArena):
* profiler/ProfilerCompilation.cpp:
(JSC::Profiler::Compilation::executionCounterFor):
* runtime/Error.cpp:
(JSC::getStackTrace):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::ensureRareDataSlow):
* runtime/FunctionRareData.h:
(JSC::FunctionRareData::createAllocationProfileClearingWatchpoint):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::createRareDataIfNeeded):
* runtime/JSRunLoopTimer.cpp:
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData):
(JSC::JSRunLoopTimer::Manager::registerVM):
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::addDeletedOffset):
* runtime/PropertyTable.cpp:
(JSC::PropertyTable::PropertyTable):
* runtime/RegExp.cpp:
(JSC::RegExp::finishCreation):
* runtime/RegExp.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
* runtime/Structure.cpp:
(JSC::Structure::ensurePropertyReplacementWatchpointSet):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::setObjectToStringValue):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::localToEntry):
(JSC::SymbolTable::cloneScopePart):
(JSC::SymbolTable::prepareForTypeProfiling):
(JSC::SymbolTable::setRareDataCodeBlock):
* runtime/TypeSet.cpp:
(JSC::StructureShape::propertyHash):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureHeapProfiler):
(JSC::VM::enableTypeProfiler):
(JSC::VM::enableControlFlowProfiler):
(JSC::VM::queueMicrotask):
(JSC::VM::ensureShadowChicken):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitPatchpoint):
(JSC::Wasm::AirIRGenerator::emitCheck):
(JSC::Wasm::parseAndCompileAir):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::complete):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::Worklist):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::compile):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
(JSC::Yarr::ByteCompiler::regexBegin):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::compile):
* yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::charClass):
(JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
(JSC::Yarr::YarrPatternConstructor::resetForReparsing):
(JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
(JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
(JSC::Yarr::YarrPatternConstructor::copyDisjunction):
(JSC::Yarr::anycharCreate):
* yarr/YarrPattern.h:
(JSC::Yarr::PatternDisjunction::addNewAlternative):
* yarr/create_regex_tables:
* yarr/generateYarrUnicodePropertyTables.py:
2019-08-18 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Correct a->an in error messages and API docblocks
https://bugs.webkit.org/show_bug.cgi?id=200833
Reviewed by Don Olmstead.
* API/JSObjectRef.h:
* builtins/PromiseConstructor.js:
(race):
(reject):
(resolve):
* builtins/PromisePrototype.js:
(finally):
* jsc.cpp:
(functionAsyncTestStart):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseIfStatement):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseResizableLimits):
2019-08-17 Darin Adler <darin@apple.com>
Tidy up checks to see if a character is in the Latin-1 range by using isLatin1 consistently
https://bugs.webkit.org/show_bug.cgi?id=200861
Reviewed by Ross Kirsling.
* parser/Lexer.cpp:
(JSC::Lexer<T>::record8): Use isLatin1.
(JSC::assertCharIsIn8BitRange): Deleted. Can just assert isLatin1 directly.
(JSC::Lexer<T>::append8): Assert isLatin1 directly.
(JSC::characterRequiresParseStringSlowCase): Use isLatin1.
* parser/Lexer.h:
(JSC::Lexer<UChar>::isWhiteSpace): Ditto.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::Lexer::lex): Ditto.
(JSC::isSafeStringCharacter): Ditto.
* runtime/Identifier.cpp:
(JSC::Identifier::add8): Ditto.
* runtime/LiteralParser.cpp:
(JSC::isSafeStringCharacter): Ditto.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncRepeatCharacter): Ditto.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): Ditto.
(JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy): Ditto.
(JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy): Ditto.
2019-08-17 Ross Kirsling <ross.kirsling@sony.com>
[ESNext] Implement optional chaining
https://bugs.webkit.org/show_bug.cgi?id=200199
Reviewed by Yusuke Suzuki.
Implement the optional chaining proposal, which has now reached Stage 3 at TC39.
This introduces a ?. operator which:
- guards member access when the LHS is nullish, i.e. `null?.foo` and `null?.['foo']` are undefined
- guards function calls when the LHS is nullish, i.e. `null?.()` is undefined
- short-circuits over a whole access/call chain, i.e. `null?.a['b'](c++)` is undefined and does not increment c
This feature can be naively viewed as a ternary in disguise, i.e. `a?.b` is like `a == null ? undefined : a.b`.
However, since we must be sure not to double-evaluate the LHS, it's actually rather akin to a try block --
namely, we have the bytecode generator keep an early-out label for use throughout the access and call chain.
(Also note that document.all behaves as an object, so "nullish" means *strictly* equal to null or undefined.)
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushOptionalChainTarget): Added.
(JSC::BytecodeGenerator::popOptionalChainTarget): Added.
(JSC::BytecodeGenerator::emitOptionalCheck): Added.
* bytecompiler/BytecodeGenerator.h:
Implement early-out logic.
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
(JSC::DotAccessorNode::emitBytecode):
(JSC::EvalFunctionCallNode::emitBytecode): Refactor so we can emitOptionalCheck in a single location.
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode): Refactor so we can emitOptionalCheck in a single location.
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::DeleteBracketNode::emitBytecode):
(JSC::DeleteDotNode::emitBytecode):
(JSC::CoalesceNode::emitBytecode): Clean up.
(JSC::OptionalChainNode::emitBytecode): Added.
Implement ?. node and emit checks where needed.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
Have OpIsUndefinedOrNull support constant registers.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createOptionalChain): Added.
(JSC::ASTBuilder::makeDeleteNode):
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/Lexer.cpp:
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
* parser/NodeConstructors.h:
(JSC::OptionalChainNode::OptionalChainNode): Added.
* parser/Nodes.h:
(JSC::ExpressionNode::isOptionalChain const): Added.
(JSC::ExpressionNode::isOptionalChainBase const): Added.
(JSC::ExpressionNode::setIsOptionalChainBase): Added.
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::makeFunctionCallNode):
(JSC::SyntaxChecker::createOptionalChain): Added.
Introduce new token and AST node, as well as an ExpressionNode field to mark LHSes with.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
Parse optional chains by wrapping the access/call parse loop.
* runtime/ExceptionHelpers.cpp:
(JSC::functionCallBase):
Ensure that TypeError messages don't include the '?.'.
* runtime/Options.h:
Update feature flag, as ?. and ?? are a double feature of "nullish-aware" operators.
2019-08-17 Ross Kirsling <ross.kirsling@sony.com>
[ESNext] Support hashbang.
https://bugs.webkit.org/show_bug.cgi?id=200865
Reviewed by Mark Lam.
Hashbang (a.k.a. shebang) support is at Stage 3 in TC39:
https://github.com/tc39/proposal-hashbang
This allows `#!` to be treated like `//`, but only at the very start of the source text.
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer):
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
2019-08-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG ToNumber should support Boolean in fixup
https://bugs.webkit.org/show_bug.cgi?id=200864
Reviewed by Mark Lam.
ToNumber should speculate on Boolean, or BooleanOrInt32 in fixup phase to optimize it.
ToT Patched
to-number-boolean 897.6430+-26.8843 ^ 87.4802+-5.2831 ^ definitely 10.2611x faster
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupToNumber):
2019-08-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] WebAssembly BBQ should switch compile mode for size of modules
https://bugs.webkit.org/show_bug.cgi?id=200807
Reviewed by Mark Lam.
Some webpages use very large Wasm module, and it exhausts all executable memory in ARM64 devices since the size of executable memory region is 128MB.
The long term solution should be introducing Wasm interpreter. But as a short term solution, we introduce heuristics switching back to BBQ B3 at
the sacrifice of start-up time, since BBQ Air bloats such lengthy code, and thereby consumes a large amount of executable memory.
Currently, I picked 10MB since the reported website is using 11MB wasm module.
* runtime/Options.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::parseAndCompileAir):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::compileFunctions):
* wasm/WasmModuleInformation.h:
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseCode):
* wasm/WasmStreamingParser.cpp:
(JSC::Wasm::StreamingParser::parseCodeSectionSize):
2019-08-16 Mark Lam <mark.lam@apple.com>
More missing exception checks in string comparison operators.
https://bugs.webkit.org/show_bug.cgi?id=200844
<rdar://problem/54378684>
Reviewed by Saam Barati.
* runtime/Operations.h:
(JSC::jsLess):
(JSC::jsLessEq):
2019-08-16 Mark Lam <mark.lam@apple.com>
CodeBlock destructor should clear all of its watchpoints.
https://bugs.webkit.org/show_bug.cgi?id=200792
<rdar://problem/53947800>
Reviewed by Yusuke Suzuki.
We need to clear the watchpoints explicitly (just like we do in CodeBlock::jettison())
because the JITCode may outlive the CodeBlock for a while. For example, the JITCode
is ref'd in Interpreter::execute(JSC::CallFrameClosure&) like so:
JSValue result = closure.functionExecutable->generatedJITCodeForCall()->execute(&vm, closure.protoCallFrame);
The call to generatedJITCodeForCall() returns a Ref<JITCode> with the underlying
JITCode ref'd. Hence, while the interpreter frame is still on the stack, the
executing JITCode instance will have a non-zero refCount, and be kept alive even
though its CodeBlock may have already been destructed.
Note: the Interpreter execute() methods aren't the only ones who would ref the JITCode:
ExecutableBase also holds a RefPtr<JITCode> m_jitCodeForCall and RefPtr<JITCode>
m_jitCodeForConstruct. But a CodeBlock will be uninstalled before it gets destructed.
Hence, the uninstallation will deref the JITCode before we get to the CodeBlock
destructor. That said, we should be aware that a JITCode's refCount is not always
1 after the JIT installs it into the CodeBlock, and it should not be assumed to be so.
For this patch, I also audited all Watchpoint subclasses to ensure that we are
clearing all the relevant watchpoints in the CodeBlock destructor. Here is the
list of audited Watchpoints:
CodeBlockJettisoningWatchpoint
AdaptiveStructureWatchpoint
AdaptiveInferredPropertyValueWatchpoint
- these are held in the DFG::CommonData, and is tied to JITCode's life cycle.
- they need to be cleared eagerly in CodeBlock's destructor.
LLIntPrototypeLoadAdaptiveStructureWatchpoint
- stored in m_llintGetByIdWatchpointMap in the CodeBlock.
- this will be automatically cleared on CodeBlock destruction.
The following does not reference CodeBlock:
FunctionRareData::AllocationProfileClearingWatchpoint
- stored in FunctionRareData and will be cleared automatically on
FunctionRareData destruction.
- only references the owner FunctionRareData.
ObjectToStringAdaptiveStructureWatchpoint
ObjectToStringAdaptiveInferredPropertyValueWatchpoint
- stored in StructureRareData and will be cleared automatically on
StructureRareData destruction.
ObjectPropertyChangeAdaptiveWatchpoint
- stored in JSGlobalObject, and will be cleared automatically on
JSGlobalObject destruction.
- only references the owner JSGlobalObject.
StructureStubClearingWatchpoint
- stored in WatchpointsOnStructureStubInfo and will be cleared automatically
on WatchpointsOnStructureStubInfo destruction.
PropertyWatchpoint
StructureWatchpoint
- embedded in AdaptiveInferredPropertyValueWatchpointBase, which is extended
as AdaptiveInferredPropertyValueWatchpoint, ObjectPropertyChangeAdaptiveWatchpoint,
and ObjectToStringAdaptiveInferredPropertyValueWatchpoint.
- life cycle is handled by those 3 subclasses.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
2019-08-16 Justin Michaud <justin_michaud@apple.com>
Fix InBounds speculation of typed array PutByVal and add extra step to integer range optimization to search for equality relationships on the RHS value
https://bugs.webkit.org/show_bug.cgi?id=200782
Reviewed by Saam Barati.
Speculate that putByVals on typed arrays are in bounds initially, and add an extra rule to integer range optimization to
remove CheckInBounds when we are looping over two arrays. We do this by fixing a bug in the llint slow paths that marked
typed array accesses as out of bounds, and we also add an extra step to integer range optimization to search for equality
relationships on the RHS value.
Microbenchmarks give a 40% improvement on the memcpy loop test, and neutral on the out-of-bounds typed array test.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGOperations.cpp:
(JSC::DFG::putByVal):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSGenericTypedArrayView.h:
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline):
(JSC::JSObject::canGetIndexQuickly const):
(JSC::JSObject::getIndexQuickly const):
(JSC::JSObject::tryGetIndexQuickly const):
(JSC::JSObject::canSetIndexQuickly):
(JSC::JSObject::setIndexQuickly):
* runtime/JSObjectInlines.h:
(JSC::JSObject::canGetIndexQuicklyForTypedArray const):
(JSC::JSObject::canSetIndexQuicklyForTypedArray const):
(JSC::JSObject::getIndexQuicklyForTypedArray const):
(JSC::JSObject::setIndexQuicklyForTypedArray):
2019-08-16 Mark Lam <mark.lam@apple.com>
[Re-land] ProxyObject should not be allow to access its target's private properties.
https://bugs.webkit.org/show_bug.cgi?id=200739
<rdar://problem/53972768>
Reviewed by Yusuke Suzuki.
Re-landing this after r200829 which resolves the test262 failure uncovered by this patch.
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performDefineOwnProperty):
2019-08-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Promise.prototype.finally should accept non-promise objects
https://bugs.webkit.org/show_bug.cgi?id=200829
Reviewed by Mark Lam.
According to the Promise.prototype.finally spec step 2[1], we should check @isObject instead of @isPromise,
since Promise.prototype.finally should accept thenable objects that are defined by user libraries (like, bluebird for example).
This patch changes this check to the specified one.
[1]: https://tc39.es/proposal-promise-finally/
* builtins/PromisePrototype.js:
(finally):
2019-08-16 Alexey Shvayka <shvaikalesh@gmail.com>
Promise constructor should check argument before [[Construct]]
https://bugs.webkit.org/show_bug.cgi?id=198976
Reviewed by Ross Kirsling.
Check if argument is a function before invoking `createSubclassStructure`.
(step 2 of https://tc39.es/ecma262/#sec-promise-executor)
* builtins/PromiseOperations.js:
(globalPrivate.initializePromise): Remove typeof check.
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise): Add isFunction check.
2019-08-16 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r248709.
Caused test/built-ins/Promise/prototype/finally/this-value-
non-promise.js to fail on test262 bot
Reverted changeset:
"ProxyObject should not be allow to access its target's
private properties."
https://bugs.webkit.org/show_bug.cgi?id=200739
https://trac.webkit.org/changeset/248709
2019-08-15 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Add makeUnique<T>, which ensures T is fast-allocated, WTF_MAKE_FAST_ALLOCATED annotation part
https://bugs.webkit.org/show_bug.cgi?id=200620
Reviewed by Geoffrey Garen.
Three patches including this one were originally one patch. I split it into three pieces to make roll-out easy.
This part, we annotate classes / structs with WTF_MAKE_FAST_ALLOCATED and WTF_MAKE_STRUCT_FAST_ALLOCATED if
they are allocated from std::make_unique. The second patch will switch `std::make_unique` to `WTF::makeUnique` and
the third patch will insert a static_assert that makeUnique-allocated class T is FastMalloc-ed.
One insight from this patch is that we tend to forget adding WTF_MAKE_STRUCT_FAST_ALLOCATED if it is just a data struct.
* debugger/Debugger.h:
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/should-strip-comments.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result:
* inspector/scripts/tests/generic/expected/version.json-result:
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
2019-08-15 Brent Fulgham <bfulgham@apple.com>
[FTW] Enable CoreFoundation use if building for Apple target
https://bugs.webkit.org/show_bug.cgi?id=200799
Reviewed by Alex Christensen.
* PlatformFTW.cmake: Add missing files.
2019-08-15 Alexey Shvayka <shvaikalesh@gmail.com>
DateConversion::formatDateTime incorrectly formats negative years
https://bugs.webkit.org/show_bug.cgi?id=199964
Reviewed by Ross Kirsling.
Currently, year is always padded to max length of 4, including the minus sign "-".
With this change, only absolute value of year is padded to max length of 4 and
preceded by minus sign "-" if the year is negative.
(steps 6-10 of https://tc39.es/ecma262/#sec-datestring)
* runtime/DateConversion.cpp:
(JSC::appendNumber):
2019-08-15 Mark Lam <mark.lam@apple.com>
More missing exception checks in String.prototype.
https://bugs.webkit.org/show_bug.cgi?id=200762
<rdar://problem/54333896>
Reviewed by Michael Saboff.
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpString):
(JSC::stringProtoFuncLastIndexOf):
(JSC::stringProtoFuncToLowerCase):
(JSC::stringProtoFuncToUpperCase):
2019-08-15 Joseph Pecoraro <pecoraro@apple.com>
for-await-of has bad error message if used in non-async function
https://bugs.webkit.org/show_bug.cgi?id=200758
Reviewed by Ross Kirsling.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
Improve error message.
2019-08-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Air does not appropriately propagate ConstFloatValue to stackmap
https://bugs.webkit.org/show_bug.cgi?id=200759
Reviewed by Saam Barati.
In B3MoveConstant phase, we convert ConstFloatValue and ConstDoubleValue to memory access to the table
to avoid large immediates *except for* stackmap argument case. This is because materializing constant doubles
and floats as memory-access before passing it to stackmap is wasteful: the stackmap may not use it actually, or
stackmap can do better job if it knows the parameter is constant.
Based on the above operation, B3LowerToAir phase strongly assumes that all ConstFloatValue and ConstDoubleValue
are removed except for the case used for parameter of stackmap. With r192377, B3LowerToAir catch this case, and
propagate constant double value as ValueRep in stackmap. While B3LowerToAir does this correctly for ConstDoubleValue,
we missed adding this support for ConstFloatValue.
This patch adds r192377's support for ConstFloatValue to propagate ConstFloatValue correctly to the stackmap.
This issue starts appearing since Wasm BBQ-B3 OSR starts putting ConstFloatValue to OSR-tier-up patchpoint.
* b3/B3LowerToAir.cpp:
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::floatValue const):
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::constantFloat):
(JSC::B3::ValueRep::floatValue const):
* b3/testb3.h:
* b3/testb3_1.cpp:
(run):
* b3/testb3_5.cpp:
(testPatchpointManyWarmAnyImms):
(testPatchpointManyColdAnyImms):
(testPatchpointManyImms): Deleted.
2019-08-14 Keith Rollin <krollin@apple.com>
Remove support for macOS < 10.13
https://bugs.webkit.org/show_bug.cgi?id=200694
<rdar://problem/54278851>
Reviewed by Youenn Fablet.
Update conditionals that reference __MAC_OS_X_VERSION_MIN_REQUIRED and
__MAC_OS_X_VERSION_MAX_ALLOWED, assuming that they both have values >=
101300. This means that expressions like
"__MAC_OS_X_VERSION_MIN_REQUIRED < 101300" are always False and
"__MAC_OS_X_VERSION_MIN_REQUIRED >= 101300" are always True.
* API/WebKitAvailability.h:
2019-08-14 Mark Lam <mark.lam@apple.com>
ProxyObject should not be allow to access its target's private properties.
https://bugs.webkit.org/show_bug.cgi?id=200739
<rdar://problem/53972768>
Reviewed by Yusuke Suzuki.
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performDefineOwnProperty):
2019-08-14 Mark Lam <mark.lam@apple.com>
Missing exception check in string compare.
https://bugs.webkit.org/show_bug.cgi?id=200743
<rdar://problem/53975356>
Reviewed by Michael Saboff.
* runtime/JSString.cpp:
(JSC::JSString::equalSlowCase const):
2019-08-14 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for MacroAssemblerARM64E change
https://bugs.webkit.org/show_bug.cgi?id=200703
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::farJump):
2019-08-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Less contended MetaAllocator
https://bugs.webkit.org/show_bug.cgi?id=200278
Reviewed by Mark Lam.
The profiler result of JetStream2/bomb-workers shows that we are having contention under MetaAllocator::currentStatistics.
This function is called in ExecutableAllocator::memoryPressureMultiplier, and it is called from ExecutableCounter's threshold
calculation. But MetaAllocator::currentStatistics takes a global lock inside MetaAllocator and causes contention. However,
we do not need to have a lock actually: clients of MetaAllocator::currentStatistics typically use bytesReserved and bytesAllocated
information. However, since our executable allocator is fixed-sized, bytesReserved is always the fixed size. So just reading bytesAllocated
racily is enough.
This patch attempts to reduce the contention by the following two things.
1. Read bytesAllocated racily instead of calling MetaAllocator::currentStatistics. Then ExecutableCounter does not need to take a lock.
2. page lifetime management APIs of MetaAllocator should take a second `count` parameter to batch the system calls.
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::underMemoryPressure):
(JSC::ExecutableAllocator::memoryPressureMultiplier):
(JSC::ExecutableAllocator::allocate):
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
(JSC::FixedVMPoolExecutableAllocator::memoryStart): Deleted.
(JSC::FixedVMPoolExecutableAllocator::memoryEnd): Deleted.
(JSC::FixedVMPoolExecutableAllocator::isJITPC): Deleted.
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): Deleted.
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator): Deleted.
(JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion): Deleted.
2019-08-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make PAC jump and return more explicit
https://bugs.webkit.org/show_bug.cgi?id=200703
Reviewed by Mark Lam.
This patch refactors our macro assembler, mainly related to PAC.
1. Make far-jump explicit by renaming `jump` to `farJump`.
2. Remove unused makeTailRecursiveCall and tailRecursiveCall.
3. Do not make `ARM64EAssembler::ret` as `retab`. MacroAssemblerARM64E should call `retab` explicitly instead.
* assembler/ARM64EAssembler.h:
(JSC::ARM64EAssembler::ret): Deleted.
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::farJump):
(JSC::MacroAssemblerARM64::makeTailRecursiveCall): Deleted.
(JSC::MacroAssemblerARM64::tailRecursiveCall): Deleted.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::farJump):
(JSC::MacroAssemblerARM64E::ret):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::farJump):
(JSC::MacroAssemblerARMv7::relativeTableJump):
(JSC::MacroAssemblerARMv7::tailRecursiveCall): Deleted.
(JSC::MacroAssemblerARMv7::makeTailRecursiveCall): Deleted.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::farJump):
(JSC::MacroAssemblerMIPS::tailRecursiveCall): Deleted.
(JSC::MacroAssemblerMIPS::makeTailRecursiveCall): Deleted.
* assembler/MacroAssemblerX86.h:
(JSC::MacroAssemblerX86::farJump):
(JSC::MacroAssemblerX86::jump): Deleted.
(JSC::MacroAssemblerX86::tailRecursiveCall): Deleted.
(JSC::MacroAssemblerX86::makeTailRecursiveCall): Deleted.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::farJump):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::farJump):
(JSC::MacroAssemblerX86_64::jump): Deleted.
(JSC::MacroAssemblerX86_64::tailRecursiveCall): Deleted.
(JSC::MacroAssemblerX86_64::makeTailRecursiveCall): Deleted.
* b3/B3LowerMacros.cpp:
* b3/testb3_6.cpp:
(testInterpreter):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
(JSC::DFG::osrEntryThunkGenerator):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::jumpToExceptionHandler):
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
(JSC::JIT::emitSlow_op_loop_hint):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
(JSC::JIT::emit_op_switch_string):
* jit/ThunkGenerators.cpp:
(JSC::slowPathFor):
(JSC::virtualThunkFor):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmThunks.cpp:
(JSC::Wasm::throwExceptionFromWasmThunkGenerator):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::emitThrowWasmToJSException):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::loadFromFrameAndJump):
2019-08-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove bad semicolon in generation of ObjC methods
https://bugs.webkit.org/show_bug.cgi?id=200655
Reviewed by Devin Rousso.
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
Do not include a semicolon in the method implementation.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
Updated results.
2019-08-13 Saam Barati <sbarati@apple.com>
Add a way to opt out of kern TCSM for layout tests
https://bugs.webkit.org/show_bug.cgi?id=200649
<rdar://problem/51304923>
Reviewed by Alexey Proskuryakov.
* assembler/CPU.cpp:
(JSC::isKernTCSMAvailable):
* runtime/Options.h:
2019-08-13 Sam Weinig <weinig@apple.com>
Rename StringBuilder::append(UChar32) to StringBuilder::appendCharacter(UChar32) to avoid accidental change in behavior when replacing append with flexibleAppend
https://bugs.webkit.org/show_bug.cgi?id=200675
Reviewed by Darin Adler.
* yarr/YarrParser.h:
(JSC::Yarr::Parser::tryConsumeGroupName):
(JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
Update for rename from StringBuilder::append(UChar32) to StringBuilder::appendCharacter(UChar32).
2019-08-13 Mark Lam <mark.lam@apple.com>
Add phase, block, and node numbers to left margin of DFG graph dumps.
https://bugs.webkit.org/show_bug.cgi?id=200693
Reviewed by Saam Barati.
When scrolling through the DFG graph dumps, it's easy to get lost as to which phase
or block one is looking at, especially if the blocks are long. This patch adds
node index, block number, and phase number on the left margin of the dumps.
Here's a sample:
53: %Bd:Function = 0x1079fd960:[Function, {}, NonArray, Proto:0x1079d8000, Leaf]
53: %Bf:Function = 0x1079b0700:[Function, {name:100, prototype:101, length:102, stackTraceLimit:103}, NonArray, Proto:0x1079d8000, Leaf]
53: %Bj:Function = 0x1079fd5e0:[Function, {name:100, length:101, toString:102, apply:103, call:104, bind:105, Symbol.hasInstance:106, caller:107, arguments:108, constructor:109}, NonArray, Proto:0x1079c0000, Leaf]
53: %CV:JSGlobalLexicalEnvironment = 0x1079fd6c0:[JSGlobalLexicalEnvironment, {}, NonArray, Leaf]
53: Phase liveness analysis changed the IR.
54: Beginning DFG phase OSR availability analysis.
54: Before OSR availability analysis:
54: DFG for foo#DXMNag:[0x1079a4850->0x1079a4130->0x1079c7600, DFGFunctionCall, 204 (NeverInline)]:
54: Fixpoint state: FixpointConverged; Form: SSA; Unification state: GloballyUnified; Ref count state: ExactRefCount
54: Argument formats for entrypoint index: 0 : FlushedJSValue, FlushedCell, FlushedJSValue
0 54: Block #0 (bc#0): (OSR target)
0 54: Execution count: 1.000000
0 54: Predecessors:
0 54: Successors:
0 54: Dominated by: #0
0 54: Dominates: #0
0 54: Dominance Frontier:
0 54: Iterated Dominance Frontier:
0 54: Backwards dominates by: #root #0
0 54: Backwards dominates: #0
0 54: Control equivalent to: #0
0 54: States: StructuresAreWatched
0 54: Live:
0 54: Values
0 0 54: 53:< 1:-> JSConstant(JS|UseAsOther, Other, Null, bc#0, ExitValid)
1 0 54: 64:< 2:-> JSConstant(JS|UseAsOther, NonBoolInt32, Int32: 10, bc#0, ExitValid)
2 0 54: 3:< 5:-> JSConstant(JS|PureInt, Other, Undefined, bc#0, ExitValid)
3 0 54: 32:< 1:-> JSConstant(JS|UseAsOther, Bool, False, bc#0, ExitValid)
4 0 54: 19:< 2:-> JSConstant(JS|UseAsOther, OtherObj, Weak:Object: 0x1079d4000 with butterfly 0x0 (Structure %CV:JSGlobalLexicalEnvironment), StructureID: 31423, bc#0, ExitValid)
The numbers in the left margin before the ':' are node index (i.e. the index of the
node in the block, not to be confused with node->index() which is the node ID), block
number, and phase number respectively. Now, we can scroll thru the dumps quickly
and tell at a glance when we've scrolled passed the end of a phase, or block.
These sets of numbers can also serve as a positional marker that we can search for
to return to a node in the dump after scrolling away.
Currently, these numbers are only added to the DFG part. The FTL (from lowering
to B3 onwards) does not have this feature yet.
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::DesiredWatchpoints::dumpInContext const):
* dfg/DFGDesiredWatchpoints.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dumpCodeOrigin):
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::dumpBlockHeader):
(JSC::DFG::Prefix::dump const):
* dfg/DFGGraph.h:
(JSC::DFG::Prefix::Prefix):
(JSC::DFG::Prefix::clearBlockIndex):
(JSC::DFG::Prefix::clearNodeIndex):
(JSC::DFG::Prefix::enable):
(JSC::DFG::Prefix::disable):
(JSC::DFG::Graph::prefix):
(JSC::DFG::Graph::nextPhase):
* dfg/DFGPhase.cpp:
(JSC::DFG::Phase::beginPhase):
* dfg/DFGPhase.h:
(JSC::DFG::runAndLog):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGValueRepReductionPhase.cpp:
(JSC::DFG::ValueRepReductionPhase::convertValueRepsToDouble):
2019-08-13 Michael Saboff <msaboff@apple.com>
REGRESSION (r248533): JSC Command - Need to initializeMainThread() before processing config file
https://bugs.webkit.org/show_bug.cgi?id=200677
Reviewed by Mark Lam.
We need to initialize the main thread before calling processConfigFile() since it uses RefCounted objects
which have "is main thread" ASSERTS.
* jsc.cpp:
(jscmain):
2019-08-13 Devin Rousso <drousso@apple.com>
Web Inspector: Styles: show @supports CSS groupings
https://bugs.webkit.org/show_bug.cgi?id=200419
<rdar://problem/53971948>
Reviewed by Joseph Pecoraro.
* inspector/protocol/CSS.json:
Rename `CSSMedia` to `Grouping` and remove the `sourceLine` value, as it was never populated
and wasn't used by Web Inspector.
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
Add support for including files at the end of <WebInspector/RWIProtocol.h> for compatibility
statements so that changes to the Web Inspector protocol don't break other clients.
2019-08-13 Joseph Pecoraro <pecoraro@apple.com>
JSContext Inspector: Basic CommandLineAPI doesn't work
https://bugs.webkit.org/show_bug.cgi?id=200659
<rdar://problem/54245476>
Reviewed by Brian Burg.
* inspector/InjectedScriptSource.js:
(BasicCommandLineAPI):
Use `method` directly since it already has been setup nicely and doesn't
need to be bound. Technically this allows someone to add properties to
the CommandLineAPI methods in basic mode (`dir.property = 1`) but that
seems harmless.
2019-08-12 Sam Weinig <weinig@apple.com>
Replace multiparameter overloads of append() in StringBuilder as a first step toward standardizinging on the flexibleAppend() implementation
https://bugs.webkit.org/show_bug.cgi?id=200614
Reviewed by Darin Adler.
Renames StringBuilder::append(const LChar*, unsigned), StringBuilder::append(const UChar*, unsigned) and
StringBuilder::append(const char*, unsigned) to StringBuilder::appendCharacters(...).
Renames StringBuilder::append(const String& string, unsigned offset, unsigned length) to
StringBuilder::appendSubstring(...).
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* runtime/ConfigFile.cpp:
(JSC::ConfigFile::parse):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::Lexer::lexStringSlow):
* tools/FunctionOverrides.cpp:
(JSC::parseClause):
Update for renames.
2019-08-12 Adrian Perez de Castro <aperez@igalia.com>
[WPE][GTK] Fix building without unified sources
https://bugs.webkit.org/show_bug.cgi?id=200641
Reviewed by Žan Doberšek.
* b3/B3PatchpointSpecial.cpp: Add missing inclusion of the B3ProcedureInlines.h header.
* heap/SlotVisitor.cpp: Add missing inclusion of the BlockDirectoryInlines.h header.
2019-08-12 Yusuke Suzuki <ysuzuki@apple.com>
[WTF][JSC] Make JSC and WTF aggressively-fast-malloced
https://bugs.webkit.org/show_bug.cgi?id=200611
Reviewed by Saam Barati.
This patch aggressively puts many classes into FastMalloc. In JSC side, we grep `std::make_unique` etc. to find potentially system-malloc-allocated classes.
After this patch, all the JSC related allocations in JetStream2 cli is done from bmalloc. In the future, it would be nice that we add `WTF::makeUnique<T>` helper
function and throw a compile error if `T` is not FastMalloc annotated[1].
Putting WebKit classes in FastMalloc has many benefits.
1. Simply, it is fast.
2. vmmap can tell the amount of memory used for WebKit.
3. bmalloc can isolate WebKit memory allocation from the rest of the world. This is useful since we can know more about what component is corrupting the memory
from the memory corruption crash.
[1]: https://bugs.webkit.org/show_bug.cgi?id=200620
* API/ObjCCallbackFunction.mm:
* assembler/AbstractMacroAssembler.h:
* b3/B3PhiChildren.h:
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.h:
* b3/air/AirDisassembler.h:
* bytecode/AccessCaseSnippetParams.h:
* bytecode/CallVariant.h:
* bytecode/DeferredSourceDump.h:
* bytecode/ExecutionCounter.h:
* bytecode/GetByIdStatus.h:
* bytecode/GetByIdVariant.h:
* bytecode/InByIdStatus.h:
* bytecode/InByIdVariant.h:
* bytecode/InstanceOfStatus.h:
* bytecode/InstanceOfVariant.h:
* bytecode/PutByIdStatus.h:
* bytecode/PutByIdVariant.h:
* bytecode/ValueProfile.h:
* dfg/DFGAbstractInterpreter.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::newVariableAccessData):
* dfg/DFGFlowIndexing.h:
* dfg/DFGFlowMap.h:
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::newVariableAccessData):
* dfg/DFGMaximalFlushInsertionPhase.cpp:
(JSC::DFG::MaximalFlushInsertionPhase::newVariableAccessData):
* dfg/DFGOSRExit.h:
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGVariableAccessData.h:
* disassembler/ARM64/A64DOpcode.h:
* inspector/remote/socket/RemoteInspectorMessageParser.h:
* inspector/remote/socket/RemoteInspectorSocket.h:
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
* jit/PCToCodeOriginMap.h:
* runtime/BasicBlockLocation.h:
* runtime/DoublePredictionFuzzerAgent.h:
* runtime/JSRunLoopTimer.h:
* runtime/PromiseDeferredTimer.h:
(JSC::PromiseDeferredTimer::create): PromiseDeferredTimer should be allocated as `Ref<>` instead of `std::unique_ptr` since it is inheriting ThreadSafeRefCounted<>.
Holding such a class with std::unique_ptr could lead to potentially dangerous operations (like, someone holds it with Ref<> while it is deleted by std::unique_ptr<>).
* runtime/RandomizingFuzzerAgent.h:
* runtime/SymbolTable.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* tools/JSDollarVM.cpp:
* tools/SigillCrashAnalyzer.cpp:
* wasm/WasmFormat.h:
* wasm/WasmMemory.cpp:
* wasm/WasmSignature.h:
* yarr/YarrJIT.h:
2019-08-12 Chris Dumez <cdumez@apple.com>
Add threading assertions to RefCounted
https://bugs.webkit.org/show_bug.cgi?id=200507
Reviewed by Ryosuke Niwa.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
Disable threading assertions for DFG::Plan::m_inlineCallFrames while the JSC team
investigates.
2019-08-12 Chris Dumez <cdumez@apple.com>
Unreviewed, rolling out r248525.
Revert new threading assertions while I work on fixing the
issues they exposed
Reverted changeset:
"Add threading assertions to RefCounted"
https://bugs.webkit.org/show_bug.cgi?id=200507
https://trac.webkit.org/changeset/248525
2019-08-11 Chris Dumez <cdumez@apple.com>
Add threading assertions to RefCounted
https://bugs.webkit.org/show_bug.cgi?id=200507
Reviewed by Ryosuke Niwa.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
Disable threading assertions for DFG::Plan::m_inlineCallFrames while the JSC team
investigates.
2019-08-09 Yusuke Suzuki <ysuzuki@apple.com>
Universal XSS in JSObject::putInlineSlow and JSValue::putToPrimitive
https://bugs.webkit.org/show_bug.cgi?id=199864
Reviewed by Saam Barati.
Our JSObject::put implementation is not correct in term of the spec. Our [[Put]] implementation is something like this.
JSObject::put(object):
if (can-do-fast-path(object))
return fast-path(object);
// slow-path
do {
object-put-check-and-setter-calls(object); // (1)
object = object->prototype;
} while (is-object(object));
return do-put(object);
Since JSObject::put is registered in the methodTable, the derived classes can override it. Some of classes are adding
extra checks to this put.
Derived::put(object):
if (do-extra-check(object))
fail
return JSObject::put(object)
The problem is that Derived::put is only called when the |this| object is the Derived class. When traversing [[Prototype]] in
JSObject::put, at (1), we do not perform the extra checks added in Derived::put even if `object` is Derived one. This means that
we skip the check.
Currently, JSObject::put and WebCore checking mechanism are broken. JSObject::put should call getOwnPropertySlot at (1) to
perform the additional checks. This behavior is matching against the spec. However, currently, our JSObject::getOwnPropertySlot
does not propagate setter information. This is required to cache cacheable [[Put]] at (1) for CustomValue, CustomAccessor, and
Accessors. We also need to reconsider how to integrate static property setters to this mechanism. So, basically, this involves
large refactoring to renew our JSObject::put and JSObject::getOwnPropertySlot.
To work-around for now, we add a new TypeInfo flag, HasPutPropertySecurityCheck . And adding this flag to DOM objects
that implements the addition checks. We also add doPutPropertySecurityCheck method hook to perform the check in JSObject.
When we found this flag at (1), we perform doPutPropertySecurityCheck to properly perform the checks.
Since our JSObject::put code is old and it does not match against the spec now, we should refactor it largely. This is tracked separately in [1].
[1]: https://bugs.webkit.org/show_bug.cgi?id=200562
* runtime/ClassInfo.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCell.cpp:
(JSC::JSCell::doPutPropertySecurityCheck):
* runtime/JSCell.h:
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::getOwnPropertyDescriptor):
* runtime/JSObject.h:
(JSC::JSObject::doPutPropertySecurityCheck):
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::hasPutPropertySecurityCheck const):
2019-08-08 Per Arne Vollan <pvollan@apple.com>
[Win] Fix internal build
https://bugs.webkit.org/show_bug.cgi?id=200519
Reviewed by Alex Christensen.
The script 'generate-js-builtins.py' cannot be found when building WebCore. Copy the JavaScriptCore Scripts
folder after building JSC.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
2019-08-08 Devin Rousso <drousso@apple.com>
Web Inspector: Page: don't allow the domain to be disabled
https://bugs.webkit.org/show_bug.cgi?id=200109
Reviewed by Brian Burg.
The `PageAgent` is relied on by many of the other agents, so much so that it doesn't make
sense to support the ability to "disable" (as well as "enable") the agent.
When the first frontend connects, we should treat the `PageAgent` as active and available.
* inspector/protocol/Page.json:
Remove `enable`/`disable`.
2019-08-08 Michael Saboff <msaboff@apple.com>
OpenSource MemoryFootprint API for JSC command line tool
https://bugs.webkit.org/show_bug.cgi?id=200541
Reviewed by Saam Barati.
Use wtf/spi/darwin/ProcessMemoryFootprint.h instead of WebKitAdditions/MemoryFootprint.h
for process memory stats.
* jsc.cpp:
(MemoryFootprint::MemoryFootprint):
2019-08-08 Devin Rousso <drousso@apple.com>
Web Inspector: rename `queryObjects` to `queryInstances` for clarity
https://bugs.webkit.org/show_bug.cgi?id=200520
Reviewed by Brian Burg.
* inspector/InjectedScriptSource.js:
(queryInstances): Added.
(queryObjects):
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::queryInstances): Added.
(Inspector::JSInjectedScriptHost::queryObjects): Deleted.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionQueryInstances): Added.
(Inspector::jsInjectedScriptHostPrototypeFunctionQueryObjects): Deleted.
2019-08-08 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Add "jump if (not) undefined or null" bytecode ops
https://bugs.webkit.org/show_bug.cgi?id=200480
Reviewed by Saam Barati.
This patch introduces fused jumps for op_is_undefined_or_null, which ignores "masquerade as undefined" behavior.
This lets us fix a edge-case bug in RequireObjectCoercible (where `({ length } = document.all)` was a TypeError)
and moreover provides a very useful optimization for the new ?. and ?? operators, which have semantics centered
around op_jundefined_or_null and op_jnundefined_or_null, respectively.
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/Opcode.h:
(JSC::isBranch):
* bytecode/PreciseJumpTargetsInlines.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::Label::setLocation):
(JSC::BytecodeGenerator::emitJumpIfTrue):
(JSC::BytecodeGenerator::emitJumpIfFalse):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_jundefined_or_null): Added.
(JSC::JIT::emit_op_jnundefined_or_null): Added.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_jundefined_or_null): Added.
(JSC::JIT::emit_op_jnundefined_or_null): Added.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2019-08-07 Devin Rousso <drousso@apple.com>
Rebase inspector generator tests.
Rubber-stamped by Brian Burg.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
2019-08-07 Caio Lima <ticaiolima@gmail.com>
High number of cache miss on localTimeOffset
https://bugs.webkit.org/show_bug.cgi?id=200444
Reviewed by Darin Adler.
This patch is separating the `LocalTimeOffsetCache` for each
`WTF::TimeType` to avoid constant cache miss on pathological cases
where `gregorianDateTimeToMS` and `msToGregorianDateTime` are
intercaleted with `inputTimeType == WTF::LocalTime`. Such case
happens during execution of Facebook Messenger
(https://www.messenger.com).
* runtime/JSDateMath.cpp:
(JSC::localTimeOffset):
(JSC::gregorianDateTimeToMS):
* runtime/VM.cpp:
(JSC::VM::resetDateCache):
* runtime/VM.h:
(JSC::LocalTimeOffsetCache::LocalTimeOffsetCache):
(JSC::LocalTimeOffsetCache::reset):
2019-08-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] sampling-profiler can see garbage Wasm::Callee* pointer which is HashTable deleted / empty values
https://bugs.webkit.org/show_bug.cgi?id=200494
Reviewed by Saam Barati.
The sampling-profiler can see a garbage pointer which is like Wasm::Callee*. This can be filtered by HashSet<Callee*>.
But this is safe only when the garbage pointer is not deleted / empty values. We saw occasional crash with JetStream2/tsf-wasm.
This patch filters out these values with `HashSet<Callee*>::isValidValue`.
* wasm/WasmCalleeRegistry.h:
(JSC::Wasm::CalleeRegistry::isValidCallee):
2019-08-06 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r248289.
https://bugs.webkit.org/show_bug.cgi?id=200488
Broke internal builds (Requested by drousso on #webkit).
Reverted changeset:
"Web Inspector: Styles: show @supports CSS groupings"
https://bugs.webkit.org/show_bug.cgi?id=200419
https://trac.webkit.org/changeset/248289
2019-08-06 Devin Rousso <drousso@apple.com>
Web Inspector: allow comments in protocol JSON
https://bugs.webkit.org/show_bug.cgi?id=200104
Reviewed by Brian Burg.
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification.load_specification):
* inspector/scripts/tests/generic/should-strip-comments.json: Added.
* inspector/scripts/tests/generic/expected/should-strip-comments.json-result: Added.
2019-08-06 Per Arne Vollan <pvollan@apple.com>
[Win] Fix AppleWin build
https://bugs.webkit.org/show_bug.cgi?id=200455
Reviewed by Alex Christensen.
* CMakeLists.txt:
* shell/CMakeLists.txt:
2019-08-05 Devin Rousso <drousso@apple.com>
Web Inspector: Styles: show @supports CSS groupings
https://bugs.webkit.org/show_bug.cgi?id=200419
Reviewed by Joseph Pecoraro.
* inspector/protocol/CSS.json:
Rename `CSSMedia` to `Grouping` and remove the `sourceLine` value, as it was never populated
and wasn't used by Web Inspector.
2019-08-05 Devin Rousso <drousso@apple.com>
Can't use $0, $1 etc when inspecting Google Docs pages because the content uses these for function names
https://bugs.webkit.org/show_bug.cgi?id=195834
Reviewed by Joseph Pecoraro.
Allow the user to alias saved results by providing a different prefix (e.g. "$") from within
Web Inspector. When changing the alias, all existing saved results will update to be
reference-able from the new alias.
* inspector/protocol/Runtime.json:
Add `setSavedResultAlias` command.
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::setSavedResultAlias): Added.
* inspector/InjectedScriptHost.h:
(Inspector::InjectedScriptHost::setSavedResultAlias): Added.
(Inspector::InjectedScriptHost::savedResultAlias const): Added.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::savedResultAlias const): Added.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeAttributeSavedResultAlias): Added.
Store the saved result alias on the `InjectedScriptHost` since it is a shared object among
all `InjectedScript`.
* inspector/InjectedScriptSource.js:
(BasicCommandLineAPI):
2019-08-05 Devin Rousso <drousso@apple.com>
Web Inspector: Timelines: disable related agents when the tab is closed
https://bugs.webkit.org/show_bug.cgi?id=200118
Reviewed by Joseph Pecoraro.
Rework how `enable`/`disable` is used for timeline-related agents so that events are not sent
and data isn't kept alive when the Timelines tab isn't enabled.
* inspector/protocol/Timeline.json:
Add `enable`/`disable` commands.
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
(Inspector::InspectorHeapAgent::enable):
(Inspector::InspectorHeapAgent::disable):
2019-08-05 Devin Rousso <drousso@apple.com>
Web Inspector: rename "Stylesheet" to "Style Sheet" to match spec text
https://bugs.webkit.org/show_bug.cgi?id=200422
Reviewed by Joseph Pecoraro.
* inspector/protocol/Page.json:
2019-08-05 Michael Saboff <msaboff@apple.com>
JSC: assertion failure in SpeculativeJIT::compileGetByValOnIntTypedArray
https://bugs.webkit.org/show_bug.cgi?id=199997
Reviewed by Saam Barati.
No need to ASSERT(node->arrayMode().alreadyChecked(...)) in SpeculativeJIT::compileGetByValOnIntTypedArray()
and compileGetByValOnFloatTypedArray() as the abstract interpreter is conservative and can insert a
CheckStructureOrEmpty which will fail the ASSERT as it checks for the SpecType of the array
and not for SpecEmpty. If we added a check for the SpecEmpty in the ASSERT, there are cases where
it won't be set.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
2019-08-03 Devin Rousso <drousso@apple.com>
Web Inspector: DOM: add a special breakpoint for "All Events"
https://bugs.webkit.org/show_bug.cgi?id=200285
Reviewed by Joseph Pecoraro.
Similar to the existing "All Requests" breakpoint, there should be a way to set a breakpoint
that would pause for any DOM event, regardless of the event's name. This is useful for
situations where the event name isn't known, or where one simply wants to pause on the next
entry to the event loop.
Along these lines, make the "requestAnimationFrame", "setTimeout", and "setInterval"
event breakpoints into special breakpoints that can be added/removed via the create
breakpoint context menu. This simplifies the process for setting these breakpoints, and also
makes them more discoverable (most people wouldn't consider them to be "events").
* inspector/protocol/Debugger.json:
- Rename the `EventListener` pause reason to `Listener`.
- Split the `Timer` pause reason into `Interval` and `Timeout`.
* inspector/protocol/DOMDebugger.json:
- Split the `timer` type into `interval` and `timeout`.
- Make `eventName` optional for `addEventBreakpoint`/`removeEventBreakpoint`. When omitted,
the corresponding breakpoint that is added/removed is treated as a global breakpoint that
applies to all events of that type (e.g. a global `listener` breakpoint would pause for
any event that is fired).
2019-08-02 Keith Miller <keith_miller@apple.com>
Address comments on r248178
https://bugs.webkit.org/show_bug.cgi?id=200411
Reviewed by Saam Barati.
* b3/B3Opcode.h:
* b3/B3Procedure.h:
(JSC::B3::Procedure::tuples const):
* b3/B3Validate.cpp:
* b3/testb3_1.cpp:
(main):
2019-08-02 Mark Lam <mark.lam@apple.com>
[ARM64E] Harden the diversity of the DOMJIT::Signature::unsafeFunction pointer.
https://bugs.webkit.org/show_bug.cgi?id=200292
<rdar://problem/53706881>
Reviewed by Geoffrey Garen.
Previously, DOMJIT::Signature::functionWithoutTypeCheck was signed as a C function
pointer. We can do better by signing it like a vtbl function pointer.
No new tests needed. The DOMJIT mechanism is covered by existing tests.
I also manually confirmed that DOMJIT::Signature::functionWithoutTypeCheck is signed
exactly as expected by reading its bits out of memory (not letting Clang have a
chance to resign it into a C function pointer) and comparing it against manually
signed bits with the expected diversifier.
* assembler/MacroAssemblerCodeRef.h:
(JSC::CFunctionPtr::CFunctionPtr):
(JSC::CFunctionPtr::get const):
(JSC::CFunctionPtr::address const):
(JSC::CFunctionPtr::operator bool const):
(JSC::CFunctionPtr::operator! const):
(JSC::CFunctionPtr::operator== const):
(JSC::CFunctionPtr::operator!= const):
- Introduce a CFunctionPtr abstraction that is used to hold pointers to C functions.
It can instantiated in 4 ways:
1. The default constructor.
2. A constructor that takes a nullptr_t.
These 2 forms will instantiate a CFunctionPtr with a nullptr.
3. A constructor that takes the name of a function.
4. A constructor that takes a function pointer.
Form 3 already knows that we're initializing with a real function, and
that Clang will give it to use signed as a C function pointer. So, it
doesn't do any assertions. This form is useful for initializing CFunctionPtrs
embedded in const data structures.
Form 4 is an explicit constructor that takes an arbitrary function
pointer, but does not know if that pointer is already signed as a C function
pointer. Hence, this form will do a RELEASE_ASSERT that the given function
pointer is actually signed as a C function pointer.
Once instantiated, we are guaranteed that a C function pointer is either null
or contains a signed C function pointer.
* domjit/DOMJITSignature.h:
(JSC::DOMJIT::Signature::Signature):
- Sign functionWithoutTypeCheck as WTF_VTBL_FUNCPTR_PTRAUTH(DOMJITFunctionPtrTag).
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
- Use the new CFunctionPtr to document that the retrieved signature->functionWithoutTypeCheck
is signed as a C function pointer.
* runtime/ClassInfo.h:
- Update MethodTable to sign its function pointers using the new WTF_VTBL_FUNCPTR_PTRAUTH_STR
to be consistent. No longer need to roll its own PTRAUTH macro.
* runtime/JSCPtrTag.h:
- Add DOMJITFunctionPtrTag.
* tools/JSDollarVM.cpp:
- Update to work with the new DOMJIT::Signature constructor.
2019-08-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Support WebAssembly in SamplingProfiler
https://bugs.webkit.org/show_bug.cgi?id=200329
Reviewed by Saam Barati.
The sampling profiler support is critical to investigate what is actually time-consuming. This patch adds the sampling profiler support for Wasm functions
to list up hot Wasm functions with compilation mode (BBQ or OMG). This allows us to investigate the hot functions in JetStream2 wasm tests.
In order to retrieve wasm function information from the sampling profiler safely, we need to know whether the given Wasm CalleeBits is valid in the call frame.
To achieve this, we start collecting valid Wasm::Callee pointers in a global hash set. Previously, each Wasm::Callee registered its code region to a hash set
for wasm fault signal handler to know whether the faulted program-counter is in wasm region. We reuse and change this mechanism. Instead of registering code region,
we register Wasm::Callee* to a hash set. The sampling profiler reuses this hash set to determine whether the given bits is a valid Wasm::Callee.
The sampling profiler retrieves the information safely from valid Wasm::Callee* pointer. It is possible that this Wasm::Callee is about to be dead: ref-count is 0,
now in the middle of the destructor of Wasm::Callee. Even in that case, fields of Wasm::Callee are still valid and can be accessed since destroying these fields happens
after we unregister Wasm::Callee from the global hash set.
We retrieve Wasm::IndexOrName and Wasm::CompilationMode. Copying them does not involve any allocations, locking etc. So we can safely copy them while some of threads are suspended.
This patch also fixes the issue that we never called `unregisterCode` while every Wasm::Calllee registers its code region through `registerCode`.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::recordJSFrame):
(JSC::CFrameWalker::CFrameWalker):
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
(JSC::SamplingProfiler::StackFrame::functionStartLine):
(JSC::SamplingProfiler::StackFrame::functionStartColumn):
(JSC::SamplingProfiler::StackFrame::sourceID):
(JSC::SamplingProfiler::StackFrame::url):
(JSC::SamplingProfiler::reportTopBytecodes):
(WTF::printInternal):
* runtime/SamplingProfiler.h:
* tools/JSDollarVM.cpp:
(JSC::functionIsWasmSupported):
(JSC::JSDollarVM::finishCreation):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::complete):
* wasm/WasmBBQPlanInlines.h:
(JSC::Wasm::BBQPlan::initializeCallees):
* wasm/WasmCallee.cpp:
(JSC::Wasm::Callee::Callee):
(JSC::Wasm::Callee::~Callee):
* wasm/WasmCallee.h:
(JSC::Wasm::Callee::create): Deleted.
(JSC::Wasm::Callee::entrypoint const): Deleted.
(JSC::Wasm::Callee::calleeSaveRegisters): Deleted.
(JSC::Wasm::Callee::indexOrName const): Deleted.
* wasm/WasmCalleeRegistry.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
(JSC::Wasm::CalleeRegistry::initialize):
(JSC::Wasm::CalleeRegistry::singleton):
* wasm/WasmCalleeRegistry.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
(JSC::Wasm::CalleeRegistry::getLock):
(JSC::Wasm::CalleeRegistry::registerCallee):
(JSC::Wasm::CalleeRegistry::unregisterCallee):
(JSC::Wasm::CalleeRegistry::isValidCallee):
* wasm/WasmCompilationMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
(JSC::Wasm::makeString):
* wasm/WasmCompilationMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
(JSC::Wasm::enableFastMemory):
(JSC::Wasm::registerCode): Deleted.
(JSC::Wasm::unregisterCode): Deleted.
* wasm/WasmFaultSignalHandler.h:
* wasm/WasmIndexOrName.h:
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
2019-08-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] LazyJSValue should be robust for empty JSValue
https://bugs.webkit.org/show_bug.cgi?id=200388
Reviewed by Saam Barati.
If the Switch DFG node is preceded by ForceOSRExit or something that invalidates the basic block,
it can take a FrozenValue as a child which includes empty value instead of string, number etc.
If this Switch node is kept and we reached to DFGCFGSimplificationPhase, it will use this FrozenValue.
However, LazyJSValue using this FrozenValue strongly assumes that FrozenValue is never holding empty value.
But this assumption is wrong. This patch makes LazyJSValue robust for empty value.
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::tryGetStringImpl const):
(JSC::DFG::LazyJSValue::tryGetString const):
(JSC::DFG::LazyJSValue::strictEqual const):
(JSC::DFG::LazyJSValue::switchLookupValue const):
2019-08-02 Devin Rousso <drousso@apple.com>
Web Inspector: Storage: disable related agents when the tab is closed
https://bugs.webkit.org/show_bug.cgi?id=200117
Reviewed by Joseph Pecoraro.
Rework how `enable`/`disable` is used for storage-related agents so that events are not sent
and data isn't kept alive when the Storage tab isn't enabled.
* inspector/protocol/ApplicationCache.json:
Add `disable` command.
2019-08-01 Keith Miller <keith_miller@apple.com>
B3 should support tuple types
https://bugs.webkit.org/show_bug.cgi?id=200327
Reviewed by Filip Pizlo.
As part of the Wasm multi-value proposal, we need to teach B3 that
patchpoints can return more than one value. This is done by
adding a new B3::Type called Tuple. Unlike, other B3 types Tuple
is actually an encoded index into a numeric B3::Type vector on the
procedure. This lets us distinguish any two tuples from each
other, moreover, it's possible to get the vector of types with
just the B3::Tuple type and the procedure.
Since most B3 operations only expect to see a single numeric child
there is a new Opcode, Extract, that takes yields the some, fixed,
entry from a tuple value. Extract would be the only other change
needed to make tuples work in B3 except that some optimizations
expect to be able to take any non-Void value and stick it into a
Variable of the same type. This means both Get/Set from a variable
have to support Tuples as well. For simplicity and consistency,
the ability to accept tuples is also applied to Phi and Upsilon.
In order to lower a Tuple, B3Lowering needs to have a Tmp for each
nested type in a Tuple. While we could reuse the existing
IndexedTables to hold the extra information we need to lower
Tuples, we instead use a two new HashTables for Value->Tmp(s) and
Phi->Tmp(s). It's expected that Tuples will be sufficiently
uncommon the overhead of tracking everything together would be
prohibitive. On the other hand, we don't worry about this for
Variables because we don't expect those to make it to lowering.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/B3Bank.h:
(JSC::B3::bankForType):
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::CheckValue):
* b3/B3ExtractValue.cpp: Copied from Source/JavaScriptCore/b3/B3ProcedureInlines.h.
(JSC::B3::ExtractValue::~ExtractValue):
(JSC::B3::ExtractValue::dumpMeta const):
* b3/B3ExtractValue.h: Copied from Source/JavaScriptCore/b3/B3FixSSA.h.
* b3/B3FixSSA.h:
* b3/B3LowerMacros.cpp:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3LowerToAir.cpp:
* b3/B3NativeTraits.h:
* b3/B3Opcode.cpp:
(JSC::B3::invertedCompare):
(WTF::printInternal):
* b3/B3Opcode.h:
(JSC::B3::opcodeForConstant):
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
(JSC::B3::PatchpointSpecial::isValid):
(JSC::B3::PatchpointSpecial::admitsStack):
(JSC::B3::PatchpointSpecial::generate):
* b3/B3PatchpointValue.cpp:
(JSC::B3::PatchpointValue::dumpMeta const):
(JSC::B3::PatchpointValue::PatchpointValue):
* b3/B3PatchpointValue.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addTuple):
(JSC::B3::Procedure::isValidTuple const):
(JSC::B3::Procedure::tupleForType const):
(JSC::B3::Procedure::addIntConstant):
(JSC::B3::Procedure::addConstant):
* b3/B3Procedure.h:
(JSC::B3::Procedure::returnCount const):
* b3/B3ProcedureInlines.h:
(JSC::B3::Procedure::extractFromTuple const):
* b3/B3ReduceStrength.cpp:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::isValidImpl):
(JSC::B3::StackmapSpecial::isArgValidForType):
(JSC::B3::StackmapSpecial::isArgValidForRep):
(JSC::B3::StackmapSpecial::isArgValidForValue): Deleted.
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.h:
* b3/B3Type.cpp:
(WTF::printInternal):
* b3/B3Type.h:
(JSC::B3::Type::Type):
(JSC::B3::Type::tupleFromIndex):
(JSC::B3::Type::kind const):
(JSC::B3::Type::tupleIndex const):
(JSC::B3::Type::hash const):
(JSC::B3::Type::operator== const):
(JSC::B3::Type::operator!= const):
(JSC::B3::Type::isInt const):
(JSC::B3::Type::isFloat const):
(JSC::B3::Type::isNumeric const):
(JSC::B3::Type::isTuple const):
(JSC::B3::sizeofType):
(JSC::B3::isInt): Deleted.
(JSC::B3::isFloat): Deleted.
* b3/B3TypeMap.h:
(JSC::B3::TypeMap::at):
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::isRounded const):
(JSC::B3::Value::effects const):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/B3ValueInlines.h:
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::intConstant):
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::hash const):
* b3/B3ValueRep.h:
* b3/B3Width.h:
(JSC::B3::widthForType):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::canRepresent const):
* b3/air/AirArg.h:
* b3/air/AirCCallingConvention.cpp:
(JSC::B3::Air::cCallResult):
* b3/air/AirLowerMacros.cpp:
(JSC::B3::Air::lowerMacros):
* b3/testb3.h:
(populateWithInterestingValues):
* b3/testb3_1.cpp:
(run):
* b3/testb3_3.cpp:
(testStorePartial8BitRegisterOnX86):
* b3/testb3_5.cpp:
(testPatchpointWithRegisterResult):
(testPatchpointWithStackArgumentResult):
(testPatchpointWithAnyResult):
* b3/testb3_6.cpp:
(testPatchpointDoubleRegs):
(testSomeEarlyRegister):
* b3/testb3_7.cpp:
(testShuffleDoesntTrashCalleeSaves):
(testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead):
(testSimpleTuplePair):
(testSimpleTuplePairUnused):
(testSimpleTuplePairStack):
(tailDupedTuplePair):
(tuplePairVariableLoop):
(tupleNestedLoop):
(addTupleTests):
* b3/testb3_8.cpp:
(testLoad):
(addLoadTests):
* ftl/FTLAbbreviatedTypes.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
(JSC::FTL::DFG::LowerDFGToB3::compileCPUIntrinsic):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
(JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
(JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitPatchpoint):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::marshallArgument const):
(JSC::Wasm::CallingConvention::setupFrameInPrologue const):
(JSC::Wasm::CallingConvention::setupCall const):
(JSC::Wasm::CallingConventionAir::setupCall const):
2019-08-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use "destroy" function directly for JSWebAssemblyCodeBlock and WebAssemblyFunction
https://bugs.webkit.org/show_bug.cgi?id=200385
Reviewed by Mark Lam.
These CellTypes are not using classInfo stored in the cells, so we can just call JSWebAssemblyCodeBlock::destroy
and WebAssemblyFunction::destroy directly.
* wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp:
(JSC::JSWebAssemblyCodeBlockDestroyFunc::operator() const):
* wasm/js/WebAssemblyFunctionHeapCellType.cpp:
(JSC::WebAssemblyFunctionDestroyFunc::operator() const):
2019-08-02 Mark Lam <mark.lam@apple.com>
Gardening: build fix.
https://bugs.webkit.org/show_bug.cgi?id=200149
<rdar://problem/53570112>
Not reviewed.
* assembler/CPU.cpp:
(JSC::hwPhysicalCPUMax):
2019-08-01 Yusuke Suzuki <ysuzuki@apple.com>
GetterSetter type confusion during DFG compilation
https://bugs.webkit.org/show_bug.cgi?id=199903
Reviewed by Mark Lam.
In AI, we are strongly assuming that GetGetter's child constant value should be GetterSetter if it exists.
However, this can be wrong since nobody ensures that. AI assumed so because the control-flow and preceding
CheckStructure ensures that. But this preceding check can be eliminated if the node becomes (at runtime) unreachable.
Let's consider the following graph.
129:<!0:-> PutByOffset(KnownCell:@115, KnownCell:@115, Check:Untyped:@124, MustGen, id5{length}, 0, W:NamedProperties(5), ClobbersExit, bc#154, ExitValid)
130:<!0:-> PutStructure(KnownCell:@115, MustGen, %C8:Object -> %C3:Object, ID:7726, R:JSObject_butterfly, W:JSCell_indexingType,JSCell_structureID,JSCell_typeInfoFlags,JSCell_typeInfoType, ClobbersExit, bc#154, ExitInvalid)
...
158:<!0:-> GetLocal(Check:Untyped:@197, JS|MustGen|UseAsOther, Final, loc7(R<Final>/FlushedCell), R:Stack(-8), bc#187, ExitValid) predicting Final
210:< 1:-> DoubleRep(Check:NotCell:@158, Double|PureInt, BytecodeDouble, Exits, bc#187, ExitValid)
...
162:<!0:-> CheckStructure(Cell:@158, MustGen, [%Ad:Object], R:JSCell_structureID, Exits, bc#192, ExitValid)
163:< 1:-> GetGetterSetterByOffset(KnownCell:@158, KnownCell:@158, JS|UseAsOther, OtherCell, id5{length}, 0, R:NamedProperties(5), Exits, bc#192, ExitValid)
164:< 1:-> GetGetter(KnownCell:@163, JS|UseAsOther, Function, R:GetterSetter_getter, Exits, bc#192, ExitValid)
At @163 and @164, AI proves that @158's AbstractValue is None because @210's edge filters out Cells @158 is a cell. But we do not invalidate graph status as "Invalid" even if edge filters out all possible value.
This is because the result of edge can be None in a valid program. For example, we can put a dependency edge between a consuming node and a producing node, where the producing node is just like a check and it
does not produce a value actually. So, @163 and @164 are not invalidated. This is totally fine in our compiler pipeline right now.
But after that, global CSE phase found that @115 and @158 are same and @129 dominates @158. As a result, we can replace GetGetter child's @163 with @124. Since CheckStructure is already removed (and now, at runtime,
@163 and @164 are never executed), we do not have any structure guarantee on @158 and the result of @163. This means that @163's CSE result can be non-GetterSetter value.
124:< 2:-> JSConstant(JS|UseAsOther, Final, Weak:Object: 0x1199e82a0 with butterfly 0x0 (Structure %B4:Object), StructureID: 49116, bc#0, ExitValid)
...
126:< 2:-> GetGetter(KnownCell:Kill:@124, JS|UseAsOther, Function, R:GetterSetter_getter, Exits, bc#192, ExitValid)
AI filters out @124's non-cell values. But @126 can get non-GetterSetter cell at AI phase. But our AI code is like the following.
JSValue base = forNode(node->child1()).m_value;
if (base) {
GetterSetter* getterSetter = jsCast<GetterSetter*>(base);
...
Then, jsCast casts the above object with GetterSetter accidentally.
In general, DFG AI can get a proven constant value, which could not be shown at runtime. This happens if the processing node is unreachable at runtime while the graph is not invalid yet, because preceding edge
filters already filter out all the possible execution. DFG AI already considered about this possibility, and it attempts to fold a node into a constant only when the constant input matches against the expected one.
But several DFG nodes are not handling this correctly: GetGetter, GetSetter, and SkipScope.
In this patch, we use `jsDynamicCast` to ensure that the constant input matches against the expected (foldable) one, and fold it only when the expectation is met.
We also remove DFG::Node::castConstant and its use. We should not rely on the constant folded value based on graph's control-flow.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGNode.h:
(JSC::DFG::Node::castConstant): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
2019-08-01 Mark Lam <mark.lam@apple.com>
Add crash diagnostics for debugging unexpected zapped cells.
https://bugs.webkit.org/show_bug.cgi?id=200149
<rdar://problem/53570112>
Reviewed by Yusuke Suzuki.
Add a check for zapped cells in SlotVisitor::appendToMarkStack() and
SlotVisitor::visitChildren(). If a zapped cell is detected, we will crash with
some diagnostic info.
To facilitate this, we've made the following changes:
1. Changed FreeCell to preserve the 1st 8 bytes. This is fine to do because all
cells are at least 16 bytes long.
2. Changed HeapCell::zap() to only zap the structureID. Leave the rest of the
cell header info intact (including the cell JSType).
3. Changed HeapCell::zap() to record the reason for zapping the cell. We stash
the reason immediately after the first 8 bytes. This is the same location as
FreeCell::scrambledNext. However, since a cell is not expected to be zapped
and on the free list at the same time, it is also fine to do this.
4. Added a few utility functions to MarkedBlock for checking if a cell points
into the block.
5. Added VMInspector and JSDollarVM utilities to dump in-use subspace hashes.
6. Added some comments to document the hashes of known subspaces.
7. Added Options::dumpZappedCellCrashData() to make this check conditional.
We use this option to disable this check for slower machines so that their
PLT5 performance is not impacted.
* assembler/CPU.cpp:
(JSC::hwL3CacheSize):
(JSC::hwPhysicalCPUMax):
* assembler/CPU.h:
(JSC::hwL3CacheSize):
(JSC::hwPhysicalCPUMax):
* heap/FreeList.h:
(JSC::FreeCell::offsetOfScrambledNext):
* heap/HeapCell.h:
(JSC::HeapCell::zap):
(JSC::HeapCell::isZapped const):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::stopAllocating):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::start const):
(JSC::MarkedBlock::Handle::end const):
(JSC::MarkedBlock::Handle::contains const):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::specializedSweep):
* heap/MarkedSpace.h:
(JSC::MarkedSpace::forEachSubspace):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
(JSC::SlotVisitor::reportZappedCellAndCrash):
* heap/SlotVisitor.h:
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
* runtime/Options.cpp:
(JSC::Options::initialize):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* tools/JSDollarVM.cpp:
(JSC::functionDumpSubspaceHashes):
(JSC::JSDollarVM::finishCreation):
* tools/VMInspector.cpp:
(JSC::VMInspector::dumpSubspaceHashes):
* tools/VMInspector.h:
2019-08-01 Keith Miller <keith_miller@apple.com>
Fix bug in testMulImm32SignExtend
https://bugs.webkit.org/show_bug.cgi?id=200358
Reviewed by Mark Lam.
Also, have it run in more configurations.
* b3/testb3_2.cpp:
(testMulImm32SignExtend):
* b3/testb3_3.cpp:
(addArgTests):
2019-07-31 Mark Lam <mark.lam@apple.com>
Rename DOMJIT safe/unsafeFunction to functionWithTypeChecks and functionWithoutTypeChecks.
https://bugs.webkit.org/show_bug.cgi?id=200323
Reviewed by Yusuke Suzuki.
The DOMJIT has a notion of a safeFunction and an unsafeFunction. The safeFunction
is effectively the same as the unsafeFunction with added type check. The DFG/FTL
will emit code to call the unsafeFunction if it has already emitted the needed
type check or proven that it isn't needed. Otherwise, the DFG/FTL will emit
code to call the safeFunction (which does its own type check) instead.
This patch renames these functions to better describe their difference.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
* domjit/DOMJITSignature.h:
(JSC::DOMJIT::Signature::Signature):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* tools/JSDollarVM.cpp:
(JSC::DOMJITFunctionObject::functionWithTypeCheck):
(JSC::DOMJITFunctionObject::functionWithoutTypeCheck):
(JSC::DOMJITFunctionObject::finishCreation):
(JSC::DOMJITCheckSubClassObject::functionWithTypeCheck):
(JSC::DOMJITCheckSubClassObject::functionWithoutTypeCheck):
(JSC::DOMJITCheckSubClassObject::finishCreation):
(JSC::DOMJITFunctionObject::safeFunction): Deleted.
(JSC::DOMJITFunctionObject::unsafeFunction): Deleted.
(JSC::DOMJITCheckSubClassObject::safeFunction): Deleted.
(JSC::DOMJITCheckSubClassObject::unsafeFunction): Deleted.
2019-07-31 Alex Christensen <achristensen@webkit.org>
Begin organizing b3 tests
https://bugs.webkit.org/show_bug.cgi?id=200330
Reviewed by Keith Miller.
* b3/testb3.h:
* b3/testb3_1.cpp:
(run):
(zero): Deleted.
(negativeZero): Deleted.
* b3/testb3_2.cpp:
(testBitXorTreeArgs):
(testBitXorTreeArgsEven):
(testBitXorTreeArgImm):
(testBitAndTreeArg32):
(testBitOrTreeArg32):
(testBitAndArgs):
(testBitAndSameArg):
(testBitAndNotNot):
(testBitAndNotImm):
(testBitAndImms):
(testBitAndArgImm):
(testBitAndImmArg):
(testBitAndBitAndArgImmImm):
(testBitAndImmBitAndArgImm):
(testBitAndArgs32):
(testBitAndSameArg32):
(testBitAndImms32):
(testBitAndArgImm32):
(testBitAndImmArg32):
(testBitAndBitAndArgImmImm32):
(testBitAndImmBitAndArgImm32):
(testBitAndWithMaskReturnsBooleans):
(testBitAndArgDouble):
(testBitAndArgsDouble):
(testBitAndArgImmDouble):
(testBitAndImmsDouble):
(testBitAndArgFloat):
(testBitAndArgsFloat):
(testBitAndArgImmFloat):
(testBitAndImmsFloat):
(testBitAndArgsFloatWithUselessDoubleConversion):
(testBitOrArgs):
(testBitOrSameArg):
(testBitOrAndAndArgs):
(testBitOrAndSameArgs):
(testBitOrNotNot):
(testBitOrNotImm):
(testBitOrImms):
(testBitOrArgImm):
(testBitOrImmArg):
(testBitOrBitOrArgImmImm):
(testBitOrImmBitOrArgImm):
(testBitOrArgs32):
(testBitOrSameArg32):
(testBitOrImms32):
(testBitOrArgImm32):
(testBitOrImmArg32):
(addBitTests):
* b3/testb3_3.cpp:
(testSShrArgs):
(testSShrImms):
(testSShrArgImm):
(testSShrArg32):
(testSShrArgs32):
(testSShrImms32):
(testSShrArgImm32):
(testZShrArgs):
(testZShrImms):
(testZShrArgImm):
(testZShrArg32):
(testZShrArgs32):
(testZShrImms32):
(testZShrArgImm32):
(zero):
(negativeZero):
(addArgTests):
(addCallTests):
(addShrTests):
* b3/testb3_4.cpp:
(addSExtTests):
* b3/testb3_6.cpp:
(testSShrShl32):
(testSShrShl64):
(addSShrShTests):
2019-07-31 Devin Rousso <drousso@apple.com>
Web Inspector: Debugger: support emulateUserGesture parameter in Debugger.evaluateOnCallFrame
https://bugs.webkit.org/show_bug.cgi?id=200272
Reviewed by Joseph Pecoraro.
When paused, evaluating in the console should still respect the "Emulate User Gesture" checkbox.
* inspector/protocol/Debugger.json:
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
2019-07-31 Alex Christensen <achristensen@webkit.org>
Split testb3 into multiple files
https://bugs.webkit.org/show_bug.cgi?id=200326
Reviewed by Keith Miller.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/testb3.cpp: Removed.
* b3/testb3.h: Added.
(hiddenTruthBecauseNoReturnIsStupid):
(usage):
(shouldBeVerbose):
(compileProc):
(invoke):
(compileAndRun):
(lowerToAirForTesting):
(checkDisassembly):
(checkUsesInstruction):
(checkDoesNotUseInstruction):
(populateWithInterestingValues):
(floatingPointOperands):
(int64Operands):
(int32Operands):
(add32):
(modelLoad):
(float>):
(double>):
* b3/testb3_1.cpp: Added.
(zero):
(negativeZero):
(shouldRun):
(testRotR):
(testRotL):
(testRotRWithImmShift):
(testRotLWithImmShift):
(testComputeDivisionMagic):
(run):
(main):
(dllLauncherEntryPoint):
* b3/testb3_2.cpp: Added.
(test42):
(testLoad42):
(testLoadAcq42):
(testLoadWithOffsetImpl):
(testLoadOffsetImm9Max):
(testLoadOffsetImm9MaxPlusOne):
(testLoadOffsetImm9MaxPlusTwo):
(testLoadOffsetImm9Min):
(testLoadOffsetImm9MinMinusOne):
(testLoadOffsetScaledUnsignedImm12Max):
(testLoadOffsetScaledUnsignedOverImm12Max):
(testBitXorTreeArgs):
(testBitXorTreeArgsEven):
(testBitXorTreeArgImm):
(testAddTreeArg32):
(testMulTreeArg32):
(testBitAndTreeArg32):
(testBitOrTreeArg32):
(testArg):
(testReturnConst64):
(testReturnVoid):
(testAddArg):
(testAddArgs):
(testAddArgImm):
(testAddImmArg):
(testAddArgMem):
(testAddMemArg):
(testAddImmMem):
(testAddArg32):
(testAddArgs32):
(testAddArgMem32):
(testAddMemArg32):
(testAddImmMem32):
(testAddNeg1):
(testAddNeg2):
(testAddArgZeroImmZDef):
(testAddLoadTwice):
(testAddArgDouble):
(testAddArgsDouble):
(testAddArgImmDouble):
(testAddImmArgDouble):
(testAddImmsDouble):
(testAddArgFloat):
(testAddArgsFloat):
(testAddFPRArgsFloat):
(testAddArgImmFloat):
(testAddImmArgFloat):
(testAddImmsFloat):
(testAddArgFloatWithUselessDoubleConversion):
(testAddArgsFloatWithUselessDoubleConversion):
(testAddArgsFloatWithEffectfulDoubleConversion):
(testAddMulMulArgs):
(testMulArg):
(testMulArgStore):
(testMulAddArg):
(testMulArgs):
(testMulArgNegArg):
(testMulNegArgArg):
(testMulArgImm):
(testMulImmArg):
(testMulArgs32):
(testMulArgs32SignExtend):
(testMulImm32SignExtend):
(testMulLoadTwice):
(testMulAddArgsLeft):
(testMulAddArgsRight):
(testMulAddArgsLeft32):
(testMulAddArgsRight32):
(testMulSubArgsLeft):
(testMulSubArgsRight):
(testMulSubArgsLeft32):
(testMulSubArgsRight32):
(testMulNegArgs):
(testMulNegArgs32):
(testMulArgDouble):
(testMulArgsDouble):
(testMulArgImmDouble):
(testMulImmArgDouble):
(testMulImmsDouble):
(testMulArgFloat):
(testMulArgsFloat):
(testMulArgImmFloat):
(testMulImmArgFloat):
(testMulImmsFloat):
(testMulArgFloatWithUselessDoubleConversion):
(testMulArgsFloatWithUselessDoubleConversion):
(testMulArgsFloatWithEffectfulDoubleConversion):
(testDivArgDouble):
(testDivArgsDouble):
(testDivArgImmDouble):
(testDivImmArgDouble):
(testDivImmsDouble):
(testDivArgFloat):
(testDivArgsFloat):
(testDivArgImmFloat):
(testDivImmArgFloat):
(testDivImmsFloat):
(testModArgDouble):
(testModArgsDouble):
(testModArgImmDouble):
(testModImmArgDouble):
(testModImmsDouble):
(testModArgFloat):
(testModArgsFloat):
(testModArgImmFloat):
(testModImmArgFloat):
(testModImmsFloat):
(testDivArgFloatWithUselessDoubleConversion):
(testDivArgsFloatWithUselessDoubleConversion):
(testDivArgsFloatWithEffectfulDoubleConversion):
(testUDivArgsInt32):
(testUDivArgsInt64):
(testUModArgsInt32):
(testUModArgsInt64):
(testSubArg):
(testSubArgs):
(testSubArgImm):
(testSubNeg):
(testNegSub):
(testNegValueSubOne):
(testSubSub):
(testSubSub2):
(testSubAdd):
(testSubFirstNeg):
(testSubImmArg):
(testSubArgMem):
(testSubMemArg):
(testSubImmMem):
(testSubMemImm):
(testSubArgs32):
(testSubArgImm32):
(testSubImmArg32):
(testSubMemArg32):
(testSubArgMem32):
(testSubImmMem32):
(testSubMemImm32):
(testNegValueSubOne32):
(testNegMulArgImm):
(testSubMulMulArgs):
(testSubArgDouble):
(testSubArgsDouble):
(testSubArgImmDouble):
(testSubImmArgDouble):
(testSubImmsDouble):
(testSubArgFloat):
(testSubArgsFloat):
(testSubArgImmFloat):
(testSubImmArgFloat):
(testSubImmsFloat):
(testSubArgFloatWithUselessDoubleConversion):
(testSubArgsFloatWithUselessDoubleConversion):
(testSubArgsFloatWithEffectfulDoubleConversion):
(testTernarySubInstructionSelection):
(testNegDouble):
(testNegFloat):
(testNegFloatWithUselessDoubleConversion):
(testBitAndArgs):
(testBitAndSameArg):
(testBitAndNotNot):
(testBitAndNotImm):
(testBitAndImms):
(testBitAndArgImm):
(testBitAndImmArg):
(testBitAndBitAndArgImmImm):
(testBitAndImmBitAndArgImm):
(testBitAndArgs32):
(testBitAndSameArg32):
(testBitAndImms32):
(testBitAndArgImm32):
(testBitAndImmArg32):
(testBitAndBitAndArgImmImm32):
(testBitAndImmBitAndArgImm32):
(testBitAndWithMaskReturnsBooleans):
(bitAndDouble):
(testBitAndArgDouble):
(testBitAndArgsDouble):
(testBitAndArgImmDouble):
(testBitAndImmsDouble):
(bitAndFloat):
(testBitAndArgFloat):
(testBitAndArgsFloat):
(testBitAndArgImmFloat):
(testBitAndImmsFloat):
(testBitAndArgsFloatWithUselessDoubleConversion):
(testBitOrArgs):
(testBitOrSameArg):
(testBitOrAndAndArgs):
(testBitOrAndSameArgs):
(testBitOrNotNot):
(testBitOrNotImm):
(testBitOrImms):
(testBitOrArgImm):
(testBitOrImmArg):
(testBitOrBitOrArgImmImm):
(testBitOrImmBitOrArgImm):
(testBitOrArgs32):
(testBitOrSameArg32):
(testBitOrImms32):
(testBitOrArgImm32):
(testBitOrImmArg32):
* b3/testb3_3.cpp: Added.
(testBitOrBitOrArgImmImm32):
(testBitOrImmBitOrArgImm32):
(bitOrDouble):
(testBitOrArgDouble):
(testBitOrArgsDouble):
(testBitOrArgImmDouble):
(testBitOrImmsDouble):
(bitOrFloat):
(testBitOrArgFloat):
(testBitOrArgsFloat):
(testBitOrArgImmFloat):
(testBitOrImmsFloat):
(testBitOrArgsFloatWithUselessDoubleConversion):
(testBitXorArgs):
(testBitXorSameArg):
(testBitXorAndAndArgs):
(testBitXorAndSameArgs):
(testBitXorImms):
(testBitXorArgImm):
(testBitXorImmArg):
(testBitXorBitXorArgImmImm):
(testBitXorImmBitXorArgImm):
(testBitXorArgs32):
(testBitXorSameArg32):
(testBitXorImms32):
(testBitXorArgImm32):
(testBitXorImmArg32):
(testBitXorBitXorArgImmImm32):
(testBitXorImmBitXorArgImm32):
(testBitNotArg):
(testBitNotImm):
(testBitNotMem):
(testBitNotArg32):
(testBitNotImm32):
(testBitNotMem32):
(testNotOnBooleanAndBranch32):
(testBitNotOnBooleanAndBranch32):
(testShlArgs):
(testShlImms):
(testShlArgImm):
(testShlSShrArgImm):
(testShlArg32):
(testShlArgs32):
(testShlImms32):
(testShlArgImm32):
(testShlZShrArgImm32):
(testSShrArgs):
(testSShrImms):
(testSShrArgImm):
(testSShrArg32):
(testSShrArgs32):
(testSShrImms32):
(testSShrArgImm32):
(testZShrArgs):
(testZShrImms):
(testZShrArgImm):
(testZShrArg32):
(testZShrArgs32):
(testZShrImms32):
(testZShrArgImm32):
(countLeadingZero):
(testClzArg64):
(testClzMem64):
(testClzArg32):
(testClzMem32):
(testAbsArg):
(testAbsImm):
(testAbsMem):
(testAbsAbsArg):
(testAbsNegArg):
(testAbsBitwiseCastArg):
(testBitwiseCastAbsBitwiseCastArg):
(testAbsArgWithUselessDoubleConversion):
(testAbsArgWithEffectfulDoubleConversion):
(testCeilArg):
(testCeilImm):
(testCeilMem):
(testCeilCeilArg):
(testFloorCeilArg):
(testCeilIToD64):
(testCeilIToD32):
(testCeilArgWithUselessDoubleConversion):
(testCeilArgWithEffectfulDoubleConversion):
(testFloorArg):
(testFloorImm):
(testFloorMem):
(testFloorFloorArg):
(testCeilFloorArg):
(testFloorIToD64):
(testFloorIToD32):
(testFloorArgWithUselessDoubleConversion):
(testFloorArgWithEffectfulDoubleConversion):
(correctSqrt):
(testSqrtArg):
(testSqrtImm):
(testSqrtMem):
(testSqrtArgWithUselessDoubleConversion):
(testSqrtArgWithEffectfulDoubleConversion):
(testCompareTwoFloatToDouble):
(testCompareOneFloatToDouble):
(testCompareFloatToDoubleThroughPhi):
(testDoubleToFloatThroughPhi):
(testReduceFloatToDoubleValidates):
(testDoubleProducerPhiToFloatConversion):
(testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
(testDoubleProducerPhiWithNonFloatConst):
(testDoubleArgToInt64BitwiseCast):
(testDoubleImmToInt64BitwiseCast):
(testTwoBitwiseCastOnDouble):
(testBitwiseCastOnDoubleInMemory):
(testBitwiseCastOnDoubleInMemoryIndexed):
(testInt64BArgToDoubleBitwiseCast):
(testInt64BImmToDoubleBitwiseCast):
(testTwoBitwiseCastOnInt64):
(testBitwiseCastOnInt64InMemory):
(testBitwiseCastOnInt64InMemoryIndexed):
(testFloatImmToInt32BitwiseCast):
(testBitwiseCastOnFloatInMemory):
(testInt32BArgToFloatBitwiseCast):
(testInt32BImmToFloatBitwiseCast):
(testTwoBitwiseCastOnInt32):
(testBitwiseCastOnInt32InMemory):
(testConvertDoubleToFloatArg):
(testConvertDoubleToFloatImm):
(testConvertDoubleToFloatMem):
(testConvertFloatToDoubleArg):
(testConvertFloatToDoubleImm):
(testConvertFloatToDoubleMem):
(testConvertDoubleToFloatToDoubleToFloat):
(testLoadFloatConvertDoubleConvertFloatStoreFloat):
(testFroundArg):
(testFroundMem):
(testIToD64Arg):
(testIToF64Arg):
(testIToD32Arg):
(testIToF32Arg):
(testIToD64Mem):
(testIToF64Mem):
(testIToD32Mem):
(testIToF32Mem):
(testIToD64Imm):
(testIToF64Imm):
(testIToD32Imm):
(testIToF32Imm):
(testIToDReducedToIToF64Arg):
(testIToDReducedToIToF32Arg):
(testStore32):
(testStoreConstant):
(testStoreConstantPtr):
(testStore8Arg):
(testStore8Imm):
(testStorePartial8BitRegisterOnX86):
(testStore16Arg):
(testStore16Imm):
(testTrunc):
(testAdd1):
(testAdd1Ptr):
(testNeg32):
(testNegPtr):
(testStoreAddLoad32):
* b3/testb3_4.cpp: Added.
(testStoreRelAddLoadAcq32):
(testStoreAddLoadImm32):
(testStoreAddLoad8):
(testStoreRelAddLoadAcq8):
(testStoreRelAddFenceLoadAcq8):
(testStoreAddLoadImm8):
(testStoreAddLoad16):
(testStoreRelAddLoadAcq16):
(testStoreAddLoadImm16):
(testStoreAddLoad64):
(testStoreRelAddLoadAcq64):
(testStoreAddLoadImm64):
(testStoreAddLoad32Index):
(testStoreAddLoadImm32Index):
(testStoreAddLoad8Index):
(testStoreAddLoadImm8Index):
(testStoreAddLoad16Index):
(testStoreAddLoadImm16Index):
(testStoreAddLoad64Index):
(testStoreAddLoadImm64Index):
(testStoreSubLoad):
(testStoreAddLoadInterference):
(testStoreAddAndLoad):
(testStoreNegLoad32):
(testStoreNegLoadPtr):
(testAdd1Uncommuted):
(testLoadOffset):
(testLoadOffsetNotConstant):
(testLoadOffsetUsingAdd):
(testLoadOffsetUsingAddInterference):
(testLoadOffsetUsingAddNotConstant):
(testLoadAddrShift):
(testFramePointer):
(testOverrideFramePointer):
(testStackSlot):
(testLoadFromFramePointer):
(testStoreLoadStackSlot):
(testStoreFloat):
(testStoreDoubleConstantAsFloat):
(testSpillGP):
(testSpillFP):
(testInt32ToDoublePartialRegisterStall):
(testInt32ToDoublePartialRegisterWithoutStall):
(testBranch):
(testBranchPtr):
(testDiamond):
(testBranchNotEqual):
(testBranchNotEqualCommute):
(testBranchNotEqualNotEqual):
(testBranchEqual):
(testBranchEqualEqual):
(testBranchEqualCommute):
(testBranchEqualEqual1):
(testBranchEqualOrUnorderedArgs):
(testBranchNotEqualAndOrderedArgs):
(testBranchEqualOrUnorderedDoubleArgImm):
(testBranchEqualOrUnorderedFloatArgImm):
(testBranchEqualOrUnorderedDoubleImms):
(testBranchEqualOrUnorderedFloatImms):
(testBranchEqualOrUnorderedFloatWithUselessDoubleConversion):
(testBranchFold):
(testDiamondFold):
(testBranchNotEqualFoldPtr):
(testBranchEqualFoldPtr):
(testBranchLoadPtr):
(testBranchLoad32):
(testBranchLoad8S):
(testBranchLoad8Z):
(testBranchLoad16S):
(testBranchLoad16Z):
(testBranch8WithLoad8ZIndex):
(testComplex):
(testBranchBitTest32TmpImm):
(testBranchBitTest32AddrImm):
(testBranchBitTest32TmpTmp):
(testBranchBitTest64TmpTmp):
(testBranchBitTest64AddrTmp):
(testBranchBitTestNegation):
(testBranchBitTestNegation2):
(testSimplePatchpoint):
(testSimplePatchpointWithoutOuputClobbersGPArgs):
(testSimplePatchpointWithOuputClobbersGPArgs):
(testSimplePatchpointWithoutOuputClobbersFPArgs):
(testSimplePatchpointWithOuputClobbersFPArgs):
(testPatchpointWithEarlyClobber):
(testPatchpointCallArg):
(testPatchpointFixedRegister):
(testPatchpointAny):
(testPatchpointGPScratch):
(testPatchpointFPScratch):
(testPatchpointLotsOfLateAnys):
(testPatchpointAnyImm):
* b3/testb3_5.cpp: Added.
(testPatchpointManyImms):
(testPatchpointWithRegisterResult):
(testPatchpointWithStackArgumentResult):
(testPatchpointWithAnyResult):
(testSimpleCheck):
(testCheckFalse):
(testCheckTrue):
(testCheckLessThan):
(testCheckMegaCombo):
(testCheckTrickyMegaCombo):
(testCheckTwoMegaCombos):
(testCheckTwoNonRedundantMegaCombos):
(testCheckAddImm):
(testCheckAddImmCommute):
(testCheckAddImmSomeRegister):
(testCheckAdd):
(testCheckAdd64):
(testCheckAddFold):
(testCheckAddFoldFail):
(testCheckAddArgumentAliasing64):
(testCheckAddArgumentAliasing32):
(testCheckAddSelfOverflow64):
(testCheckAddSelfOverflow32):
(testCheckSubImm):
(testCheckSubBadImm):
(testCheckSub):
(doubleSub):
(testCheckSub64):
(testCheckSubFold):
(testCheckSubFoldFail):
(testCheckNeg):
(testCheckNeg64):
(testCheckMul):
(testCheckMulMemory):
(testCheckMul2):
(testCheckMul64):
(testCheckMulFold):
(testCheckMulFoldFail):
(testCheckMulArgumentAliasing64):
(testCheckMulArgumentAliasing32):
(testCheckMul64SShr):
(genericTestCompare):
(modelCompare):
(testCompareLoad):
(testCompareImpl):
(testCompare):
(testEqualDouble):
(simpleFunction):
(testCallSimple):
(testCallRare):
(testCallRareLive):
(testCallSimplePure):
(functionWithHellaArguments):
(testCallFunctionWithHellaArguments):
(functionWithHellaArguments2):
(testCallFunctionWithHellaArguments2):
(functionWithHellaArguments3):
(testCallFunctionWithHellaArguments3):
(testReturnDouble):
(testReturnFloat):
(simpleFunctionDouble):
(testCallSimpleDouble):
(simpleFunctionFloat):
(testCallSimpleFloat):
(functionWithHellaDoubleArguments):
(testCallFunctionWithHellaDoubleArguments):
(functionWithHellaFloatArguments):
(testCallFunctionWithHellaFloatArguments):
(testLinearScanWithCalleeOnStack):
(testChillDiv):
(testChillDivTwice):
(testChillDiv64):
(testModArg):
(testModArgs):
(testModImms):
(testModArg32):
(testModArgs32):
(testModImms32):
(testChillModArg):
(testChillModArgs):
(testChillModImms):
(testChillModArg32):
(testChillModArgs32):
(testChillModImms32):
(testLoopWithMultipleHeaderEdges):
(testSwitch):
(testSwitchSameCaseAsDefault):
(testSwitchChillDiv):
(testSwitchTargettingSameBlock):
(testSwitchTargettingSameBlockFoldPathConstant):
(testTruncFold):
(testZExt32):
(testZExt32Fold):
(testSExt32):
(testSExt32Fold):
(testTruncZExt32):
(testTruncSExt32):
(testSExt8):
(testSExt8Fold):
(testSExt8SExt8):
(testSExt8SExt16):
(testSExt8BitAnd):
(testBitAndSExt8):
(testSExt16):
(testSExt16Fold):
(testSExt16SExt16):
(testSExt16SExt8):
(testSExt16BitAnd):
(testBitAndSExt16):
(testSExt32BitAnd):
* b3/testb3_6.cpp: Added.
(testBitAndSExt32):
(testBasicSelect):
(testSelectTest):
(testSelectCompareDouble):
(testSelectCompareFloat):
(testSelectCompareFloatToDouble):
(testSelectDouble):
(testSelectDoubleTest):
(testSelectDoubleCompareDouble):
(testSelectDoubleCompareFloat):
(testSelectFloatCompareFloat):
(testSelectDoubleCompareDoubleWithAliasing):
(testSelectFloatCompareFloatWithAliasing):
(testSelectFold):
(testSelectInvert):
(testCheckSelect):
(testCheckSelectCheckSelect):
(testCheckSelectAndCSE):
(b3Pow):
(testPowDoubleByIntegerLoop):
(testTruncOrHigh):
(testTruncOrLow):
(testBitAndOrHigh):
(testBitAndOrLow):
(testBranch64Equal):
(testBranch64EqualImm):
(testBranch64EqualMem):
(testBranch64EqualMemImm):
(testStore8Load8Z):
(testStore16Load16Z):
(testSShrShl32):
(testSShrShl64):
(testTrivialInfiniteLoop):
(testFoldPathEqual):
(testLShiftSelf32):
(testRShiftSelf32):
(testURShiftSelf32):
(testLShiftSelf64):
(testRShiftSelf64):
(testURShiftSelf64):
(testPatchpointDoubleRegs):
(testSpillDefSmallerThanUse):
(testSpillUseLargerThanDef):
(testLateRegister):
(interpreterPrint):
(testInterpreter):
(testReduceStrengthCheckBottomUseInAnotherBlock):
(testResetReachabilityDanglingReference):
(testEntrySwitchSimple):
(testEntrySwitchNoEntrySwitch):
(testEntrySwitchWithCommonPaths):
(testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
(testEntrySwitchLoop):
(testSomeEarlyRegister):
(testBranchBitAndImmFusion):
(testTerminalPatchpointThatNeedsToBeSpilled):
(testTerminalPatchpointThatNeedsToBeSpilled2):
(testPatchpointTerminalReturnValue):
(testMemoryFence):
(testStoreFence):
(testLoadFence):
(testTrappingLoad):
(testTrappingStore):
(testTrappingLoadAddStore):
(testTrappingLoadDCE):
(testTrappingStoreElimination):
(testMoveConstants):
(testPCOriginMapDoesntInsertNops):
* b3/testb3_7.cpp: Added.
(testPinRegisters):
(testX86LeaAddAddShlLeft):
(testX86LeaAddAddShlRight):
(testX86LeaAddAdd):
(testX86LeaAddShlRight):
(testX86LeaAddShlLeftScale1):
(testX86LeaAddShlLeftScale2):
(testX86LeaAddShlLeftScale4):
(testX86LeaAddShlLeftScale8):
(testAddShl32):
(testAddShl64):
(testAddShl65):
(testReduceStrengthReassociation):
(testLoadBaseIndexShift2):
(testLoadBaseIndexShift32):
(testOptimizeMaterialization):
(generateLoop):
(makeArrayForLoops):
(generateLoopNotBackwardsDominant):
(oneFunction):
(noOpFunction):
(testLICMPure):
(testLICMPureSideExits):
(testLICMPureWritesPinned):
(testLICMPureWrites):
(testLICMReadsLocalState):
(testLICMReadsPinned):
(testLICMReads):
(testLICMPureNotBackwardsDominant):
(testLICMPureFoiledByChild):
(testLICMPureNotBackwardsDominantFoiledByChild):
(testLICMExitsSideways):
(testLICMWritesLocalState):
(testLICMWrites):
(testLICMFence):
(testLICMWritesPinned):
(testLICMControlDependent):
(testLICMControlDependentNotBackwardsDominant):
(testLICMControlDependentSideExits):
(testLICMReadsPinnedWritesPinned):
(testLICMReadsWritesDifferentHeaps):
(testLICMReadsWritesOverlappingHeaps):
(testLICMDefaultCall):
(testDepend32):
(testDepend64):
(testWasmBoundsCheck):
(testWasmAddress):
(testFastTLSLoad):
(testFastTLSStore):
(doubleEq):
(doubleNeq):
(doubleGt):
(doubleGte):
(doubleLt):
(doubleLte):
(testDoubleLiteralComparison):
(testFloatEqualOrUnorderedFolding):
(testFloatEqualOrUnorderedFoldingNaN):
(testFloatEqualOrUnorderedDontFold):
(functionNineArgs):
(testShuffleDoesntTrashCalleeSaves):
(testDemotePatchpointTerminal):
(testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead):
(testInfiniteLoopDoesntCauseBadHoisting):
* b3/testb3_8.cpp: Added.
(testAtomicWeakCAS):
(testAtomicStrongCAS):
(testAtomicXchg):
(addAtomicTests):
(testLoad):
(addLoadTests):
2019-07-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Emit write barrier after storing instead of before storing
https://bugs.webkit.org/show_bug.cgi?id=200193
Reviewed by Saam Barati.
I reviewed tricky GC-related code including visitChildren and manual writeBarrier, and I found that we have several problems with write-barriers.
1. Some write-barriers are emitted before stores happen
Some code like LazyProperty emits write-barrier before we store the value. This is wrong since JSC has concurrent collector. Let's consider the situation like this.
1. Cell "A" is not marked yet
2. Write-barrier is emitted onto "A"
3. Concurrent collector scans "A"
4. Store to "A"'s field happens
5. (4)'s field is not rescaned
We should emit write-barrier after stores. This patch places write-barriers after stores happen.
2. Should emit write-barrier after the stored fields are reachable from the owner.
We have code that is logically the same to the following.
```
auto data = std::make_unique<XXX>();
data->m_field.set(vm, owner, value);
storeStoreBarrier();
owner->m_data = WTFMove(data);
```
This is not correct. When write-barrier is emitted, the owner cannot reach to the field that is stored.
The actual example is AccessCase. We are emitting write-barriers with owner when creating AccessCase, but this is not
effective until this AccessCase is chained to StructureStubInfo, which is reachable from CodeBlock.
I don't think this is actually an issue because currently AccessCase generation is guarded by CodeBlock->m_lock. And CodeBlock::visitChildren takes this lock.
But emitting a write-barrier at the right place is still better. This patch places write-barriers when StructureStubInfo::addAccessCase is called.
Speculative GC fix, it was hard to reproduce the crash since we need to control concurrent collector and main thread's scheduling in an instruction-level.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::addAccessCase):
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::considerCaching):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setupGetByIdPrototypeCache):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::setMayBeNull):
* runtime/RegExpCachedResult.h:
(JSC::RegExpCachedResult::record):
2019-07-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make StructureChain less-tricky by using Auxiliary Buffer
https://bugs.webkit.org/show_bug.cgi?id=200192
Reviewed by Saam Barati.
StructureChain has a bit tricky write barrier / mutator fence to use UniqueArray for its underlying storage.
But, since the size of StructureChain is fixed at initialization, we should allocate an underlying storage from auxiliary memory and
set it in its constructor instead of finishCreation. We can store values in the finishCreation so that we do not need to have
a hacky write-barrier and mutator fence. Furthermore, we can make StructureChain non-destructible.
This patch leverages auxiliary buffer for the implementation of StructureChain. And it also adds a test that stresses StructureChain creation.
* runtime/StructureChain.cpp:
(JSC::StructureChain::StructureChain):
(JSC::StructureChain::create):
(JSC::StructureChain::finishCreation):
(JSC::StructureChain::visitChildren):
(JSC::StructureChain::destroy): Deleted.
* runtime/StructureChain.h:
2019-07-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Increment bytecode age only when SlotVisitor is first-visit
https://bugs.webkit.org/show_bug.cgi?id=200196
Reviewed by Robin Morisset.
WriteBarrier can cause multiple visits for the same UnlinkedCodeBlock. But this does not mean that we are having multiple cycles of GC.
We should increment the age of the UnlinkedCodeBlock only when the SlotVisitor is saying that this is the first visit.
In practice,this almost never happens. Multiple visits can happen only when the marked UnlinkedCodeBlock gets a write-barrier. But, mutation
of UnlinkedCodeBlock is rare or none after it is initialized. I ran all the JSTests and I cannot find any tests that get re-visiting of UnlinkedCodeBlock.
This patch extends JSTests/stress/reparsing-unlinked-codeblock.js to ensure that UnlinkedCodeBlockJettisoning feature is working after this change.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildren):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::isFirstVisit const):
* parser/Parser.cpp:
* parser/Parser.h:
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
* runtime/Options.h:
* tools/JSDollarVM.cpp:
(JSC::functionParseCount):
(JSC::JSDollarVM::finishCreation):
2019-07-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r247886.
https://bugs.webkit.org/show_bug.cgi?id=200214
"Causes PLT5 regression on some machines" (Requested by mlam|a
on #webkit).
Reverted changeset:
"Add crash diagnostics for debugging unexpected zapped cells."
https://bugs.webkit.org/show_bug.cgi?id=200149
https://trac.webkit.org/changeset/247886
2019-07-27 Justin Michaud <justin_michaud@apple.com>
[X86] Emit BT instruction for shift + mask in B3
https://bugs.webkit.org/show_bug.cgi?id=199891
Reviewed by Keith Miller.
- Add a new BranchTestBit air opcode, matching the intel bt instruction
- Select this instruction for the following patterns:
if (a & (1<<b))
if ((a>>b)&1)
if ((~a>>b)&1)
if (~a & (1<<b))
- 15% perf progression on the nonconstant microbenchmark, neutral otherwise.
- Note: we cannot fuse loads when we have bitBase=Load, bitOffset=Tmp, since the X86 instruction has
different behaviour in this mode. It will read past the current dword/qword instead of wrapping around.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchTestBit32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branchTestBit64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::bt_ir):
(JSC::X86Assembler::bt_im):
(JSC::X86Assembler::btw_ir):
(JSC::X86Assembler::btw_im):
* assembler/testmasm.cpp:
(JSC::int64Operands):
(JSC::testBranchTestBit32RegReg):
(JSC::testBranchTestBit32RegImm):
(JSC::testBranchTestBit32AddrImm):
(JSC::testBranchTestBit64RegReg):
(JSC::testBranchTestBit64RegImm):
(JSC::testBranchTestBit64AddrImm):
(JSC::run):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testBranchBitTest32TmpImm):
(JSC::B3::testBranchBitTest32AddrImm):
(JSC::B3::testBranchBitTest32TmpTmp):
(JSC::B3::testBranchBitTest64TmpTmp):
(JSC::B3::testBranchBitTest64AddrTmp):
(JSC::B3::run):
2019-07-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Potential GC fix for JSPropertyNameEnumerator
https://bugs.webkit.org/show_bug.cgi?id=200151
Reviewed by Mark Lam.
We have been seeing some JSPropertyNameEnumerator::visitChildren crashes for a long time. The crash frequency itself is not high, but it has existed for a long time.
The crash happens when visiting m_propertyNames. It is also possible that this crash is caused by random corruption somewhere, but JSPropertyNameEnumerator
has some tricky (and potentially dangerous) implementations anyway.
1. JSPropertyNameEnumerator have Vector<WriteBarrier<JSString>> and it is extended in finishCreation with a lock.
We should use Auxiliary memory for this use case. And we should set this memory in the constructor so that
we do not extend it in finishCreation, and we do not need a lock.
2. JSPropertyNameEnumerator gets StructureID before allocating JSPropertyNameEnumerator. This is potentially dangerous because the conservative scan
cannot find the Structure* since we could only have StructureID. Since allocation code happens after StructureID is retrieved, it is possible that
the allocation causes GC and Structure* is collected.
In this patch, we align JSPropertyNameEnumerator implementation to the modern one to avoid using Vector<WriteBarrier<JSString>>. And we can make JSPropertyNameEnumerator
a non-destructible cell. Since JSCell's destructor is one of the cause of various issues, we should avoid it if we can.
No behavior change. This patch adds a test stressing JSPropertyNameEnumerator.
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::create):
(JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
(JSC::JSPropertyNameEnumerator::finishCreation):
(JSC::JSPropertyNameEnumerator::visitChildren):
(JSC::JSPropertyNameEnumerator::destroy): Deleted.
* runtime/JSPropertyNameEnumerator.h:
* runtime/VM.cpp:
(JSC::VM::emptyPropertyNameEnumeratorSlow):
* runtime/VM.h:
(JSC::VM::emptyPropertyNameEnumerator):
2019-07-26 Mark Lam <mark.lam@apple.com>
Add crash diagnostics for debugging unexpected zapped cells.
https://bugs.webkit.org/show_bug.cgi?id=200149
<rdar://problem/53570112>
Reviewed by Yusuke Suzuki, Saam Barati, and Michael Saboff.
Add a check for zapped cells in SlotVisitor::appendToMarkStack() and
SlotVisitor::visitChildren(). If a zapped cell is detected, we will crash with
some diagnostic info.
To facilitate this, we've made the following changes:
1. Changed FreeCell to preserve the 1st 8 bytes. This is fine to do because all
cells are at least 16 bytes long.
2. Changed HeapCell::zap() to only zap the structureID. Leave the rest of the
cell header info intact (including the cell JSType).
3. Changed HeapCell::zap() to record the reason for zapping the cell. We stash
the reason immediately after the first 8 bytes. This is the same location as
FreeCell::scrambledNext. However, since a cell is not expected to be zapped
and on the free list at the same time, it is also fine to do this.
4. Added a few utility functions to MarkedBlock for checking if a cell points
into the block.
5. Added VMInspector and JSDollarVM utilities to dump in-use subspace hashes.
6. Added some comments to document the hashes of known subspaces.
* heap/FreeList.h:
(JSC::FreeCell::offsetOfScrambledNext):
* heap/HeapCell.h:
(JSC::HeapCell::zap):
(JSC::HeapCell::isZapped const):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::stopAllocating):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::start const):
(JSC::MarkedBlock::Handle::end const):
(JSC::MarkedBlock::Handle::contains const):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::specializedSweep):
* heap/MarkedSpace.h:
(JSC::MarkedSpace::forEachSubspace):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
(JSC::SlotVisitor::reportZappedCellAndCrash):
* heap/SlotVisitor.h:
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
* runtime/VM.cpp:
(JSC::VM::VM):
* tools/JSDollarVM.cpp:
(JSC::functionDumpSubspaceHashes):
(JSC::JSDollarVM::finishCreation):
* tools/VMInspector.cpp:
(JSC::VMInspector::dumpSubspaceHashes):
* tools/VMInspector.h:
2019-07-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use unalignedLoad for JSRopeString fiber accesses
https://bugs.webkit.org/show_bug.cgi?id=200148
Reviewed by Mark Lam.
JSRopeString always have some subsequent bytes that can be accessible because MarkedBlock has Footer.
We use WTF::unalignedLoad to get fibers. And it will be converted to one load CPU instruction.
* heap/MarkedBlock.h:
* runtime/JSString.h:
2019-07-25 Ross Kirsling <ross.kirsling@sony.com>
Legacy numeric literals should not permit separators or BigInt
https://bugs.webkit.org/show_bug.cgi?id=199984
Reviewed by Keith Miller.
* parser/Lexer.cpp:
(JSC::Lexer<T>::parseOctal):
(JSC::Lexer<T>::parseDecimal):
2019-07-25 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix due to C++17's std::invoke_result_t
https://bugs.webkit.org/show_bug.cgi?id=200139
Use std::result_of for now until all the supported environments implement it.
* heap/IsoSubspace.h:
2019-07-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Ensure PackedCellPtr only takes non-large-allocation pointers
https://bugs.webkit.org/show_bug.cgi?id=200139
Reviewed by Mark Lam.
PackedCellPtr will compact a pointer by leveraging the fact that JSCell pointers are 16byte aligned.
But this fact only holds when the JSCell is not large allocation. Currently, we are using PackedCellPtr
only for the cell types which meets the above requirement. But we would like to ensure that statically.
In this patch, we add additional static/runtime assertions to ensure this invariant. We accept a cell
type of either (1) it is "final" annotated and sizeof(T) is <= MarkedSpace::largeCutoff or (2) it
is allocated from IsoSubspace.
This patch does not change any behaviors. It just adds extra static/runtime assertions.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::subspaceFor):
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/IsoSubspace.h:
* heap/PackedCellPtr.h:
(JSC::PackedCellPtr::PackedCellPtr):
* runtime/FunctionRareData.h:
(JSC::FunctionRareData::createAllocationProfileClearingWatchpoint):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h:
2019-07-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make visitChildren implementation more idiomatic
https://bugs.webkit.org/show_bug.cgi?id=200121
Reviewed by Mark Lam.
This patch makes visitChildren implementations more idiomatic: cast, assert, and calling Base::visitChildren.
While this does not find interesting issues, it is still nice to have consistent implementations.
StructureChain::visitChildren missed Base::visitChildren, but it does not have much effect since StructureChain
is immortal cell.
* bytecode/ExecutableToCodeBlockEdge.cpp:
(JSC::ExecutableToCodeBlockEdge::visitChildren):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::visitChildren):
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::visitChildren):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::visitChildren):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
* runtime/JSImmutableButterfly.cpp:
(JSC::JSImmutableButterfly::visitChildren):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::visitChildren):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::visitChildren):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::visitChildren):
* runtime/JSString.cpp:
(JSC::JSString::visitChildren):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::visitChildren):
* runtime/StructureChain.cpp:
(JSC::StructureChain::visitChildren):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::visitChildren):
* tools/JSDollarVM.cpp:
(JSC::Root::visitChildren):
(JSC::ImpureGetter::visitChildren):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::visitChildren):
2019-07-25 Ross Kirsling <ross.kirsling@sony.com>
[ESNext] Implement nullish coalescing
https://bugs.webkit.org/show_bug.cgi?id=200072
Reviewed by Darin Adler.
Implement the nullish coalescing proposal, which has now reached Stage 3 at TC39.
This introduces a ?? operator which:
- acts like || but checks for nullishness instead of truthiness
- has a precedence lower than || (or any other binary operator)
- must be disambiguated with parentheses when combined with || or &&
* bytecompiler/NodesCodegen.cpp:
(JSC::CoalesceNode::emitBytecode): Added.
Bytecode must use OpIsUndefinedOrNull and not OpNeqNull because of document.all.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeBinaryNode):
* parser/Lexer.cpp:
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
* parser/NodeConstructors.h:
(JSC::CoalesceNode::CoalesceNode): Added.
* parser/Nodes.h:
Introduce new token and AST node.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseBinaryExpression):
Implement early error.
* parser/ParserTokens.h:
Since this patch needs to shift the value of every binary operator token anyway,
let's only bother to increment their LSBs when we actually have a precedence conflict.
* parser/ResultType.h:
(JSC::ResultType::definitelyIsNull const): Added.
(JSC::ResultType::mightBeUndefinedOrNull const): Added.
(JSC::ResultType::forCoalesce): Added.
We can do better than forLogicalOp here; let's be as accurate as possible.
* runtime/Options.h:
Add runtime feature flag.
2019-07-24 Alexey Shvayka <shvaikalesh@gmail.com>
Three checks are missing in Proxy internal methods
https://bugs.webkit.org/show_bug.cgi?id=198630
Reviewed by Darin Adler.
Add three missing checks in Proxy internal methods.
These checks are necessary to maintain the invariants of the essential internal methods.
(https://github.com/tc39/ecma262/pull/666)
1. [[GetOwnProperty]] shouldn't return non-configurable and non-writable descriptor when the target's property is writable.
2. [[Delete]] should return `false` when the target has property and is not extensible.
3. [[DefineOwnProperty]] should return `true` for a non-writable input descriptor when the target's property is non-configurable and writable.
Shipping in SpiderMonkey since https://hg.mozilla.org/integration/autoland/rev/3a06bc818bc4 (version 69)
Shipping in V8 since https://chromium.googlesource.com/v8/v8.git/+/e846ad9fa5109428be50b1989314e0e4e7267919
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performInternalMethodGetOwnProperty): Add writability check.
(JSC::ProxyObject::performDelete): Add extensibility check.
(JSC::ProxyObject::performDefineOwnProperty): Add writability check.
2019-07-24 Mark Lam <mark.lam@apple.com>
Remove some unused code.
https://bugs.webkit.org/show_bug.cgi?id=200101
Reviewed by Yusuke Suzuki.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::zap): Deleted.
* heap/MarkedBlock.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMutatorMarkStack): Deleted.
* heap/SlotVisitor.h:
2019-07-24 Mark Lam <mark.lam@apple.com>
performJITMemcpy should be PACed with a non-zero diversifier when passed and called via a pointer.
https://bugs.webkit.org/show_bug.cgi?id=200100
<rdar://problem/53474939>
Reviewed by Yusuke Suzuki.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::CopyFunction::CopyFunction):
(JSC::ARM64Assembler::CopyFunction::operator()):
- I choose to use ptrauth_auth_function() here instead of retagCodePtr() because
retagCodePtr() would auth, assert, and re-pac the pointer. This is needed in
general because retagCodePtr() doesn't know that you will consume the pointer
immediately (and therefore crash imminently if a failed auth is encountered).
Since we know here that we will call with the auth'ed pointer immediately, we
can skip the assert.
This also has the benefit of letting Clang do a peephole optimization to emit
a blrab instruction with the intended diversifier, instead of emitting multiple
instructions to auth the pointer into a C function, and then using a blraaz to
do a C function call.
(JSC::ARM64Assembler::linkJumpOrCall):
(JSC::ARM64Assembler::linkCompareAndBranch):
(JSC::ARM64Assembler::linkConditionalBranch):
(JSC::ARM64Assembler::linkTestAndBranch):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* runtime/JSCPtrTag.h:
2019-07-24 Devin Rousso <drousso@apple.com>
Web Inspector: print the target of `console.screenshot` last so the target is the closest item to the image
https://bugs.webkit.org/show_bug.cgi?id=199308
Reviewed by Joseph Pecoraro.
* inspector/ConsoleMessage.h:
(Inspector::ConsoleMessage::arguments const):
* inspector/ScriptArguments.h:
* inspector/ScriptArguments.cpp:
(Inspector::ScriptArguments::getFirstArgumentAsString const): Added.
(Inspector::ScriptArguments::getFirstArgumentAsString): Deleted.
2019-07-23 Justin Michaud <justin_michaud@apple.com>
Sometimes we miss removable CheckInBounds
https://bugs.webkit.org/show_bug.cgi?id=200018
Reviewed by Saam Barati.
We failed to remove the CheckInBounds bounds because we did not see that the index was nonnegative. This is because we do not see the relationship between the two
separate zero constants that appear in the IR for the given test case. This patch re-adds the hack to de-duplicate m_zero that was removed in
<https://trac.webkit.org/changeset/241228/webkit>.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
2019-07-22 Yusuke Suzuki <ysuzuki@apple.com>
[bmalloc] Each IsoPage gets 1MB VA because VMHeap::tryAllocateLargeChunk rounds up
https://bugs.webkit.org/show_bug.cgi?id=200024
Reviewed by Saam Barati.
Discussed and we decided to use this VM tag for IsoHeap instead of CLoop stack.
* interpreter/CLoopStack.cpp:
(JSC::CLoopStack::CLoopStack):
2019-07-22 Saam Barati <sbarati@apple.com>
Turn off Wasm fast memory on iOS
https://bugs.webkit.org/show_bug.cgi?id=200016
<rdar://problem/53417726>
Reviewed by Yusuke Suzuki.
We turned them on when we disabled Gigacage on iOS. However, we re-enabled
Gigacage on iOS, but forgot to turn wasm fast memories back off.
* runtime/Options.h:
2019-07-22 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed non-unified build fix.
* runtime/CachedTypes.h:
2019-07-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make DFG Local CSE and AI conservative for huge basic block
https://bugs.webkit.org/show_bug.cgi?id=199929
<rdar://problem/49309924>
Reviewed by Filip Pizlo.
In CNN page, the main thread hangs several seconds. On less-powerful devices (like iPhone7), it hangs for ~11 seconds. This is not an acceptable behavior.
The reason of this is that the DFG compiler takes too long time in the compilation for a particular function. It takes 8765 ms even in powerful x64 machine!
DFG compiler is concurrent one. However, when GC requires all the peripheral threads to be stopped, the main thread needs to wait for the DFG compiler's stop.
DFG compiler stops at GC safepoints, and they are inserted between DFG phases. So, if some of DFG phases take very long time, the main thread is blocked during that.
As a result, the main thread is blocked due to this pathological compilation.
By measuring the time taken in each DFG phase, we found that our AI and CSE phase have a problem having quadratic complexity for # of DFG nodes in a basic block.
In this patch, we add a threshold for # of DFG nodes in a basic block. If a basic block exceeds this threshold, we use conservative but O(1) algorithm for AI and Local CSE phase.
We did not add this threshold for Global CSE since FTL has another bytecode cost threshold which prevents us from compiling the large functions. But on the other hand,
DFG should compile them because DFG is intended to be a fast compiler even for a bit larger CodeBlock.
We first attempted to reduce the threshold for DFG compilation. We are using 100000 bytecode cost for DFG compilation and it is very large. However, we found that bytecode cost
is not the problem in CNN page. The problematic function has 67904 cost, and it takes 8765 ms in x64 machine. However, JetStream2/octane-zlib has 61949 function and it only takes
~400 ms. This difference comes from the # of DFG nodes in a basic block. The problematic function has 43297 DFG nodes in one basic block and it makes AI and Local CSE super time-consuming.
Rather than relying on the bytecode cost which a bit indirectly related to this pathological compile-time, we should look into # of DFG nodes in a basic block which is more directly
related to this problem. And we also found that 61949's Octane-zlib function is very critical for performance. This fact makes a bit hard to pick a right threshold: 67904 causes the problem,
and 61949 must be compiled. This is why this patch is introducing conservative analysis instead of adjusting the threshold for DFG.
This patch has two changes.
1. DFG AI has structure transition tracking which has quadratic complexity
Structure transition tracking takes very long time since its complexity is O(N^2) where N is # of DFG nodes in a basic block.
CNN has very pathological script and it shows 43297 DFG nodes. We should reduce the complexity of this algorithm.
For now, we just say "structures are clobbered" if # of DFG nodes in a basic block exceeds the threshold (20000).
We could improve the current algorithm from O(N^2) to O(2N) without being conservative, and I'm tracking this in [1].
2. DFG Local CSE has quadratic complexity
Local CSE's clobbering iterates all the impure heap values to remove the clobbered one. Since # of impure heap values tend to be proportional to # of DFG nodes we visited,
each CSE for a basic block gets O(N^2) complexity. To avoid this, we introduce HugeMap. This has the same interface to LargeMap and SmallMap in CSE, but its clobbering
implementation just clears the map completely. We can further make this O(N) without introducing conservative behavior by using epochs. For now, we do not see such a huge basic block in
JetStream2 and Speedometer2 so I'll track it in a separate bug[2].
This patch reduces the compilation time from ~11 seconds to ~200 ms.
[1]: https://bugs.webkit.org/show_bug.cgi?id=199959
[2]: https://bugs.webkit.org/show_bug.cgi?id=200014
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransition):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransitions):
* dfg/DFGCSEPhase.cpp:
* runtime/Options.h:
2019-07-22 Zhifei Fang <zhifei_fang@apple.com>
Need to skip test cache directory data vault for non internal build
https://bugs.webkit.org/show_bug.cgi?id=199951
Reviewed by Alexey Proskuryakov.
* API/tests/testapi.mm:
(testBytecodeCacheValidation): "Cache directory `/private/tmp` is not a data vault" this error message will only be created for internal build see JSScript.mm:97
2019-07-17 Antoine Quint <graouts@apple.com>
Disable Pointer Events prior to watchOS 6
https://bugs.webkit.org/show_bug.cgi?id=199890
<rdar://problem/53206113>
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2019-07-17 Keith Miller <keith_miller@apple.com>
Force useLLInt to true on arm64_32
https://bugs.webkit.org/show_bug.cgi?id=199882
<rdar://problem/53207586>
Reviewed by Yusuke Suzuki.
Some jsc tests set useLLInt=false but on arm64_32 we don't support the JIT.
This causes the option coherency checker to get angry. We should force
useLLInt=true on arm64_32 unless useJIT=true.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2019-07-17 Christopher Reid <chris.reid@sony.com>
Bytecode cache should use FileSystem
https://bugs.webkit.org/show_bug.cgi?id=199759
Reviewed by Yusuke Suzuki.
Update bytecode cache to use platform generic FileSystem calls.
* API/JSScript.mm:
* CMakeLists.txt:
* jsc.cpp:
* runtime/CachePayload.cpp:
* runtime/CachePayload.h:
* runtime/CachedBytecode.h:
* runtime/CachedTypes.cpp:
* runtime/CachedTypes.h:
* runtime/CodeCache.cpp:
* runtime/CodeCache.h:
* runtime/Completion.cpp:
* runtime/Completion.h:
2019-07-17 Mark Lam <mark.lam@apple.com>
ArgumentsEliminationPhase should insert KillStack nodes before PutStack nodes that it adds.
https://bugs.webkit.org/show_bug.cgi?id=199821
<rdar://problem/52452328>
Reviewed by Filip Pizlo.
Excluding the ArgumentsEliminationPhase, PutStack nodes are converted from SetLocal
nodes in the SSAConversionPhase. SetLocal nodes are always preceded by MovHint nodes,
and the SSAConversionPhase always inserts a KillStack node before a MovHint node.
Hence, a PutStack node is always preceded by a KillStack node.
However, the ArgumentsEliminationPhase can convert LoadVarargs nodes into a series
of one or more PutStacks nodes, and it prepends MovHint nodes before the PutStack
nodes. However, it neglects to prepend KillStack nodes as well. Since the
ArgumentsEliminationPhase runs after the SSAConversionPhase, the PutStack nodes
added during ArgumentsElimination will not be preceded by KillStack nodes.
This patch fixes this by inserting a KillStack in the ArgumentsEliminationPhase
before it inserts a MovHint and a PutStack node.
Consider this test case which can manifest the above issue as a crash:
function inlinee(value) {
...
let tmp = value + 1;
}
function reflect() {
return inlinee.apply(undefined, arguments);
}
function test(arr) {
let object = inlinee.apply(undefined, arr); // Uses a lot of SetArgumentMaybe nodes.
reflect(); // Calls with a LoadVararg, which gets converted into a PutStack of a constant.
}
In this test case, we have a scenario where a SetArgumentMaybe's stack
slot is reused as the stack slot for a PutStack later. Here, the PutStack will
put a constant undefined value. Coincidentally, the SetArgumentMaybe may also
initialize that stack slot to a constant undefined value. Note that by the time
the PutStack executes, the SetArgumentMaybe's stack slot is dead. The liveness of
these 2 values are distinct.
However, because we were missing a KillStack before the PutStack, OSR availability
analysis gets misled into thinking that the PutStack constant value is still in the
stack slot because the value left there by the SetArgumentMaybe hasn't been killed
off yet. As a result, OSR exit code will attempt to recover the PutStack's undefined
constant by loading from the stack slot instead of materializing it. Since
SetArgumentMaybe may not actually initialize the stack slot, we get a crash in OSR
exit when we try to recover the PutStack constant value from the stack slot, and
end up using what ever junk value we read from there.
Fixing the ArgumentsEliminationPhase to insert KillStack before the PutStack
removes this conflation of the PutStack's constant value with the SetArgumentMaybe's
constant value in the same stack slot. And, OSR availability analysis will no
longer be misled to load the PutStack's constant value from the stack, but will
materialize the constant instead.
* dfg/DFGArgumentsEliminationPhase.cpp:
2019-07-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r247505.
https://bugs.webkit.org/show_bug.cgi?id=199871
"Caused failed ASSERT in stress test" (Requested by creid on
#webkit).
Reverted changeset:
"Bytecode cache should use FileSystem"
https://bugs.webkit.org/show_bug.cgi?id=199759
https://trac.webkit.org/changeset/247505
2019-07-16 Christopher Reid <chris.reid@sony.com>
Bytecode cache should use FileSystem
https://bugs.webkit.org/show_bug.cgi?id=199759
Reviewed by Yusuke Suzuki.
Update bytecode cache to use platform generic FileSystem calls.
* API/JSScript.mm:
* CMakeLists.txt:
* jsc.cpp:
* runtime/CachePayload.cpp:
* runtime/CachePayload.h:
* runtime/CachedBytecode.h:
* runtime/CachedTypes.cpp:
* runtime/CachedTypes.h:
* runtime/CodeCache.cpp:
* runtime/CodeCache.h:
* runtime/Completion.cpp:
* runtime/Completion.h:
2019-07-16 Joonghun Park <pjh0718@gmail.com>
[GTK] Fix a build warning in JavaScriptCore/API/tests/testapi.c
https://bugs.webkit.org/show_bug.cgi?id=199824
Reviewed by Alex Christensen.
* API/tests/testapi.c:
(main):
2019-07-15 Keith Miller <keith_miller@apple.com>
JSGlobalObject type macros should support feature flags and WeakRef should have one
https://bugs.webkit.org/show_bug.cgi?id=199601
Reviewed by Mark Lam.
This patch refactors the various builtin type macros to have a
parameter, which is the feature flag enabling it. Since most
builtin types are enabled by default this patch adds a new global
bool typeExposedByDefault for clarity. Note, because static hash
tables have no concept of feature flags we can't use feature flags
with lazy properties. This is probably not a big deal as features
that are off by default won't be allocated anywhere we care about
memory usage anyway.
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::stringObjectStructure const):
(JSC::JSGlobalObject::bigIntObjectStructure const): Deleted.
* runtime/Options.h:
* wasm/js/JSWebAssembly.cpp:
2019-07-15 Keith Miller <keith_miller@apple.com>
A Possible Issue of Object.create method
https://bugs.webkit.org/show_bug.cgi?id=199744
Reviewed by Yusuke Suzuki.
We should call toObject on the properties argument if it was not undefined.
See: https://tc39.es/ecma262/#sec-object.create
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorCreate):
2019-07-15 Saagar Jha <saagarjha@apple.com>
Keyword lookup can use memcmp to get around unaligned load undefined behavior
https://bugs.webkit.org/show_bug.cgi?id=199650
Reviewed by Yusuke Suzuki.
Replace KeywordLookup's hand-rolled "memcmp" with the standard version, which reduces the need to deal with
endianness and unaligned loads.
* KeywordLookupGenerator.py:
(Trie.printSubTreeAsC): Use memcmp instead of macros to test for matches.
(Trie.printAsC): Unspecialize Lexer::parseKeyword as templating over the character type reduces the amount of
code we need to generate and moves this task out of the Python script and into the C++ compiler.
2019-07-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Improve wasm wpt test results by fixing miscellaneous issues
https://bugs.webkit.org/show_bug.cgi?id=199783
Reviewed by Mark Lam.
This patch fixes miscellaneous issues in our Wasm JS API implementation to improve WPT score.
I picked trivial ones in this patch to make this easily reviewable.
1. Remove WebAssemblyPrototype. It does not exist in the spec. Merging WebAssemblyPrototype into JSWebAssembly.
2. Fix various attributes. It does not match to the usual JSC builtin's convention. But this change
is correct because they are changed to be matched against WebIDL definition, and WebAssembly implementation
follows WebIDL. In the future, we could move WebCore WebIDL things into WTF layer and even use (or leverage
some of utility functions) in our WebAssembly JS API implementation.
3. Fix how we interpret "present" in WebAssembly spec. This does not mean [[HasProperty]] result. It follows to
WebIDL spec, and it means that [[Get]] result is not undefined.
4. Add argument count check to Module.customSections, which is required because the method is defined in WebIDL.
5. Fix toNonWrappingUint32 to match it to WebIDL's conversion rule.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/WebAssembly.js: Renamed from Source/JavaScriptCore/builtins/WebAssemblyPrototype.js.
* jit/Repatch.cpp:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSModuleLoader.cpp:
(JSC::moduleLoaderParseModule):
* wasm/js/JSWebAssembly.cpp:
(JSC::JSWebAssembly::create):
(JSC::JSWebAssembly::finishCreation):
(JSC::reject):
(JSC::webAssemblyModuleValidateAsyncInternal):
(JSC::webAssemblyCompileFunc):
(JSC::resolve):
(JSC::JSWebAssembly::webAssemblyModuleValidateAsync):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::JSWebAssembly::instantiate):
(JSC::webAssemblyModuleInstantinateAsyncInternal):
(JSC::JSWebAssembly::webAssemblyModuleInstantinateAsync):
(JSC::webAssemblyInstantiateFunc):
(JSC::webAssemblyValidateFunc):
(JSC::webAssemblyCompileStreamingInternal):
(JSC::webAssemblyInstantiateStreamingInternal):
* wasm/js/JSWebAssembly.h:
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::toNonWrappingUint32):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::finishCreation):
* wasm/js/WebAssemblyInstancePrototype.cpp:
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::WebAssemblyLinkErrorConstructor::finishCreation):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
(JSC::WebAssemblyMemoryConstructor::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::webAssemblyModuleCustomSections):
(JSC::WebAssemblyModuleConstructor::finishCreation):
* wasm/js/WebAssemblyPrototype.cpp: Removed.
* wasm/js/WebAssemblyPrototype.h: Removed.
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
(JSC::WebAssemblyTableConstructor::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
2019-07-15 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, rolling out r247440.
Broke builds
Reverted changeset:
"[JSC] Improve wasm wpt test results by fixing miscellaneous
issues"
https://bugs.webkit.org/show_bug.cgi?id=199783
https://trac.webkit.org/changeset/247440
2019-07-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Improve wasm wpt test results by fixing miscellaneous issues
https://bugs.webkit.org/show_bug.cgi?id=199783
Reviewed by Mark Lam.
This patch fixes miscellaneous issues in our Wasm JS API implementation to improve WPT score.
I picked trivial ones in this patch to make this easily reviewable.
1. Remove WebAssemblyPrototype. It does not exist in the spec. Merging WebAssemblyPrototype into JSWebAssembly.
2. Fix various attributes. It does not match to the usual JSC builtin's convention. But this change
is correct because they are changed to be matched against WebIDL definition, and WebAssembly implementation
follows WebIDL. In the future, we could move WebCore WebIDL things into WTF layer and even use (or leverage
some of utility functions) in our WebAssembly JS API implementation.
3. Fix how we interpret "present" in WebAssembly spec. This does not mean [[HasProperty]] result. It follows to
WebIDL spec, and it means that [[Get]] result is not undefined.
4. Add argument count check to Module.customSections, which is required because the method is defined in WebIDL.
5. Fix toNonWrappingUint32 to match it to WebIDL's conversion rule.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/WebAssembly.js: Renamed from Source/JavaScriptCore/builtins/WebAssemblyPrototype.js.
* jit/Repatch.cpp:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSModuleLoader.cpp:
(JSC::moduleLoaderParseModule):
* wasm/js/JSWebAssembly.cpp:
(JSC::JSWebAssembly::create):
(JSC::JSWebAssembly::finishCreation):
(JSC::reject):
(JSC::webAssemblyModuleValidateAsyncInternal):
(JSC::webAssemblyCompileFunc):
(JSC::resolve):
(JSC::JSWebAssembly::webAssemblyModuleValidateAsync):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::JSWebAssembly::instantiate):
(JSC::webAssemblyModuleInstantinateAsyncInternal):
(JSC::JSWebAssembly::webAssemblyModuleInstantinateAsync):
(JSC::webAssemblyInstantiateFunc):
(JSC::webAssemblyValidateFunc):
(JSC::webAssemblyCompileStreamingInternal):
(JSC::webAssemblyInstantiateStreamingInternal):
* wasm/js/JSWebAssembly.h:
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::toNonWrappingUint32):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::finishCreation):
* wasm/js/WebAssemblyInstancePrototype.cpp:
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::WebAssemblyLinkErrorConstructor::finishCreation):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
(JSC::WebAssemblyMemoryConstructor::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::webAssemblyModuleCustomSections):
(JSC::WebAssemblyModuleConstructor::finishCreation):
* wasm/js/WebAssemblyPrototype.cpp: Removed.
* wasm/js/WebAssemblyPrototype.h: Removed.
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
(JSC::WebAssemblyTableConstructor::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
2019-07-15 Youenn Fablet <youenn@apple.com>
Enable a debug WebRTC mode without any encryption
https://bugs.webkit.org/show_bug.cgi?id=199177
<rdar://problem/52074986>
Reviewed by Eric Carlson.
* inspector/protocol/Page.json:
2019-07-15 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, attempt to fix production builds after r247403.
* JavaScriptCore.xcodeproj/project.pbxproj:
2019-07-15 Tadeu Zagallo <tzagallo@apple.com>
Concurrent GC should not rely on current phase to determine if it's safe to steal conn
https://bugs.webkit.org/show_bug.cgi?id=199786
<rdar://problem/52505197>
Reviewed by Saam Barati.
In r246507, we fixed a race condition in the concurrent GC where the mutator might steal
the conn from the collector thread while it transitions from the End phase to NotRunning.
However, that fix was not sufficient. In the case that the mutator steals the conn, and the
execution interleaves long enough for the mutator to progress to a different collection phase,
the collector will resume in a phase other than NotRunning, and hence the check added to
NotRunning will not suffice. To fix that, we add a new variable to track whether the collector
thread is running (m_collectorThreadIsRunning) and use it to determine whether it's safe to
steal the conn, rather than relying on m_currentPhase.
* heap/Heap.cpp:
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::requestCollection):
* heap/Heap.h:
2019-07-12 Keith Miller <keith_miller@apple.com>
Add API to get all the dependencies of a given JSScript
https://bugs.webkit.org/show_bug.cgi?id=199746
Reviewed by Saam Barati.
The method only returns the dependencies if the module was
actually evaluated. Technically, we know what the dependencies are
at the satisfy phase but for API simplicity we only provide that
information if the module graph was complete enough to at least
run.
This patch also fixes an issue where we would allow import
specifiers that didn't start "./" or "/". For reference, We have
this restriction to be consistent with the web/node. The
restriction exists in order to preserve namespace for
builtin-modules.
Lastly, this patch makes it so that we copy all scripts in the
API/tests/testapiScripts directory so they don't have to be
individually added to the xcode project.
* API/JSAPIGlobalObject.mm:
(JSC::computeValidImportSpecifier):
(JSC::JSAPIGlobalObject::moduleLoaderResolve):
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
* API/JSContext.mm:
(-[JSContext dependencyIdentifiersForModuleJSScript:]):
* API/JSContextPrivate.h:
* API/JSScript.h:
* API/tests/testapi.mm:
(testFetchWithTwoCycle):
(testFetchWithThreeCycle):
(testModuleBytecodeCache):
(+[JSContextFileLoaderDelegate newContext]):
(-[JSContextFileLoaderDelegate fetchModuleScript:]):
(-[JSContextFileLoaderDelegate findScriptForKey:]):
(-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
(testDependenciesArray):
(testDependenciesEvaluationError):
(testDependenciesSyntaxError):
(testDependenciesBadImportId):
(testDependenciesMissingImport):
(testObjectiveCAPI):
* API/tests/testapiScripts/dependencyListTests/badModuleImportId.js: Added.
* API/tests/testapiScripts/dependencyListTests/bar.js: Added.
* API/tests/testapiScripts/dependencyListTests/dependenciesEntry.js: Added.
* API/tests/testapiScripts/dependencyListTests/foo.js: Added.
* API/tests/testapiScripts/dependencyListTests/missingImport.js: Added.
* API/tests/testapiScripts/dependencyListTests/referenceError.js: Added.
* API/tests/testapiScripts/dependencyListTests/syntaxError.js: Added.
* API/tests/testapiScripts/testapi-function-overrides.js: Renamed from Source/JavaScriptCore/API/tests/testapi-function-overrides.js.
* API/tests/testapiScripts/testapi.js: Renamed from Source/JavaScriptCore/API/tests/testapi.js.
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ModuleLoader.js:
(dependencyKeysIfEvaluated):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::dependencyKeysIfEvaluated):
* runtime/JSModuleLoader.h:
* shell/CMakeLists.txt:
2019-07-12 Justin Michaud <justin_michaud@apple.com>
B3 should reduce (integer) Sub(Neg(x), y) to Neg(Add(x, y))
https://bugs.webkit.org/show_bug.cgi?id=196371
Reviewed by Keith Miller.
Adding these strength reductions gives 2x a (x86) and 3x (arm64) performance improvement
on the microbenchmark.
* b3/B3ReduceStrength.cpp:
* b3/testb3.cpp:
(JSC::B3::testSubSub):
(JSC::B3::testSubSub2):
(JSC::B3::testSubAdd):
(JSC::B3::testSubFirstNeg):
(JSC::B3::run):
2019-07-12 Caio Lima <ticaiolima@gmail.com>
[BigInt] Add ValueBitLShift into DFG
https://bugs.webkit.org/show_bug.cgi?id=192664
Reviewed by Saam Barati.
This patch is splitting the `BitLShift` into `ArithBitLShift` and
`ValueBitLShift` to handle BigInt speculation more efficiently during
DFG and FTL layers. Following the same approach of other `ValueBitOps`,
`ValueBitLShift` handles Untyped and BigInt speculations, while
`ArithBitLShift` handles number and boolean operands and always results into
Int32.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/Opcode.h:
* dfg/DFGAbstractInterpreter.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantBinaryBitwiseOp):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
We moved `BitLShift` constant fold rules to a new method
`handleConstantBinaryBitwiseOp` to be reused by `ArithBitLShift` and
`ValueBitLShift`. This also enables support of constant folding on other
bitwise operations like `ValueBitAnd`, `ValueBitOr` and `ValueBitXor`, when
their binary use kind is UntypedUse. Such cases can happen on those
nodes because fixup phase is conservative.
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::parseBlock):
We parse `op_lshift` as `ArithBitLShift` when its operands are numbers.
Otherwise, we fallback to `ValueBitLShift` and rely on fixup phase to
convert `ValueBitLShift` into `ArithBitLShift` when possible.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
`ArithBitLShift` has the same clobberize rules as former `BitLShift`.
`ValueBitLShift` only clobberize world when it is UntypedUse.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
`ValueBitLShift` can GC when `BigIntUse` because it allocates new
JSBigInts to perform this operation. It also can GC on UntypedUse
because of observable user code.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
`ValueBitLShift` and `ArithBitLShift` has the same fixup rules of
other binary bitwise operations. In the case of `ValueBitLShift`
We check if we should speculate on BigInt or Untyped and fallback to
`ArithBitLShift` when both cheks fail.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
We updated `operationValueBitLShift` to handle BigInt cases. Also, we
added `operationBitLShiftBigInt` that is used when we compile
`ValueBitLValueBitLShift(BigIntUse)`.
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
`ValueBitLShift`'s prediction propagation rules differs from other
bitwise operations, because using only heap prediction for this node causes
significant performance regression on Octane's zlib and mandreel.
The reason is because of cases where a function is compiled but the
instruction `op_lshift` was never executed before. If we use
`getPrediction()` we will emit a `ForceOSRExit`, resulting in more OSR
than desired. To solve such issue, we are then using
`getPredictionWithoutOSR()` and falling back to `getHeapPrediction()`
only on cases where we can't rely on node's input types.
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueLShiftOp):
(JSC::DFG::SpeculativeJIT::compileShiftOp):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::shiftOp):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitLShift):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitLShift):
(JSC::FTL::DFG::LowerDFGToB3::compileBitLShift): Deleted.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2019-07-12 Keith Miller <keith_miller@apple.com>
getIndexQuickly should be const
https://bugs.webkit.org/show_bug.cgi?id=199747
Reviewed by Yusuke Suzuki.
* runtime/Butterfly.h:
(JSC::Butterfly::indexingPayload const):
(JSC::Butterfly::arrayStorage const):
(JSC::Butterfly::contiguousInt32 const):
(JSC::Butterfly::contiguousDouble const):
(JSC::Butterfly::contiguous const):
* runtime/JSObject.h:
(JSC::JSObject::canGetIndexQuickly const):
(JSC::JSObject::getIndexQuickly const):
(JSC::JSObject::tryGetIndexQuickly const):
(JSC::JSObject::canGetIndexQuickly): Deleted.
(JSC::JSObject::getIndexQuickly): Deleted.
2019-07-11 Justin Michaud <justin_michaud@apple.com>
Add b3 macro lowering for CheckMul on arm64
https://bugs.webkit.org/show_bug.cgi?id=199251
Reviewed by Robin Morisset.
- Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
- Add a new opcode to air on arm64 for smull (multiplySignExtend32).
- Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits).
- 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark,
and no change on the no-constant benchmark.
Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
to completion.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::multiplySignExtend32):
* assembler/testmasm.cpp:
(JSC::testMul32SignExtend):
(JSC::run):
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testMulArgs32SignExtend):
(JSC::B3::testMulImm32SignExtend):
(JSC::B3::testMemoryFence):
(JSC::B3::testStoreFence):
(JSC::B3::testLoadFence):
(JSC::B3::testPinRegisters):
(JSC::B3::run):
2019-07-11 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, revert r243617.
https://bugs.webkit.org/show_bug.cgi?id=196341
Mark pointed out that JSVirtualMachine can be gone in the other thread while we are executing GC constraint-solving.
This patch does not account that JavaScriptCore.framework is multi-thread safe: JSVirtualMachine wrapper can be destroyed,
and [JSVirtualMachine dealloc] can be executed in any threads while the VM is retained and used in the other thread (e.g.
destroyed from AutoReleasePool in some thread).
* API/JSContext.mm:
(-[JSContext initWithVirtualMachine:]):
(-[JSContext dealloc]):
(-[JSContext initWithGlobalContextRef:]):
(-[JSContext wrapperMap]):
(+[JSContext contextWithJSGlobalContextRef:]):
* API/JSVirtualMachine.mm:
(initWrapperCache):
(wrapperCache):
(+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
(+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
(-[JSVirtualMachine initWithContextGroupRef:]):
(-[JSVirtualMachine dealloc]):
(+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
(-[JSVirtualMachine contextForGlobalContextRef:]):
(-[JSVirtualMachine addContext:forGlobalContextRef:]):
(scanExternalObjectGraph):
(scanExternalRememberedSet):
* API/JSVirtualMachineInternal.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::setWrapperMap):
(JSC::JSGlobalObject::setAPIWrapper): Deleted.
(JSC::JSGlobalObject::apiWrapper const): Deleted.
* runtime/VM.h:
2019-07-10 Tadeu Zagallo <tzagallo@apple.com>
Optimize join of large empty arrays
https://bugs.webkit.org/show_bug.cgi?id=199636
Reviewed by Mark Lam.
Replicate the behavior of `str.repeat(count)` when performing `new Array(count + 1).join(str)`.
I added two new microbenchmarks:
- large-empty-array-join, which does not use the result of the join and runs ~44x faster and uses ~18x less memory.
- large-empty-array-join-resolve-rope, which uses the result of the join and runs 2x faster.
baseline diff
large-empty-array-join 2713.9698+-72.7621 ^ 61.2335+-10.4836 ^ definitely 44.3217x faster
large-empty-array-join-resolve-string 26.5517+-0.3995 ^ 12.9309+-0.5516 ^ definitely 2.0533x faster
large-empty-array-join memory usage with baseline (dirty):
733012 kB current_mem
756824 kB lifetime_peak
large-empty-array-join memory usage with diff (dirty):
41904 kB current_mem
41972 kB lifetime_peak
Additionally, I ran JetStream2, sunspider and v8-spider and all were neutral.
* runtime/ArrayPrototype.cpp:
(JSC::fastJoin):
2019-07-08 Keith Miller <keith_miller@apple.com>
Enable Intl.PluralRules and Intl.NumberFormatToParts by default
https://bugs.webkit.org/show_bug.cgi?id=199288
Reviewed by Yusuke Suzuki.
These features have been around for a while. We should turn them on by default.
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::finishCreation):
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation): Deleted.
* runtime/IntlObject.h:
* runtime/Options.h:
2019-07-08 Antoine Quint <graouts@apple.com>
[Pointer Events] Enable only on the most recent version of the supported iOS family
https://bugs.webkit.org/show_bug.cgi?id=199562
<rdar://problem/52766511>
Reviewed by Dean Jackson.
* Configurations/FeatureDefines.xcconfig:
2019-07-06 Michael Saboff <msaboff@apple.com>
switch(String) needs to check for exceptions when resolving the string
https://bugs.webkit.org/show_bug.cgi?id=199541
Reviewed by Mark Lam.
Added exception checks for resolved Strings in switch processing for all tiers.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2019-07-05 Mark Lam <mark.lam@apple.com>
ArgumentsEliminationPhase::eliminateCandidatesThatInterfere() should not decrement nodeIndex pass zero.
https://bugs.webkit.org/show_bug.cgi?id=199533
<rdar://problem/52669111>
Reviewed by Filip Pizlo.
* dfg/DFGArgumentsEliminationPhase.cpp:
2019-07-05 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix build failure on ARM64_32
https://bugs.webkit.org/show_bug.cgi?id=182434
Implicit narrowing from uint64_t to uint32_t happens. We should explicitly narrow it because we already checked
the `length` is <= UINT32_MAX.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSpeciesCreate):
2019-07-05 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] Clean up ArraySpeciesCreate
https://bugs.webkit.org/show_bug.cgi?id=182434
Reviewed by Yusuke Suzuki.
We have duplicate code in arraySpeciesCreate, filter, map, concatSlowPath of ArrayPrototype.js
and speciesConstructArray of ArrayPrototype.cpp. This patch fixes cross-realm Array constructor
detection in native speciesConstructArray, upgrades `length` type to correctly handle large integers,
and exposes it as @arraySpeciesCreate. Also removes now unused @isArrayConstructor private function.
Native speciesConstructArray is preferred because it has fast path via speciesWatchpointIsValid.
Thoroughly benchmarked: this change progresses ARES-6 by 0-1%.
* builtins/ArrayPrototype.js:
(filter):
(map):
(globalPrivate.concatSlowPath):
(globalPrivate.arraySpeciesCreate): Deleted.
* builtins/BuiltinNames.h:
* runtime/ArrayConstructor.cpp:
(JSC::arrayConstructorPrivateFuncIsArrayConstructor): Deleted.
* runtime/ArrayConstructor.h:
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSpeciesCreate):
* runtime/ArrayPrototype.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2019-07-05 Tadeu Zagallo <tzagallo@apple.com>
Unreviewed, change the value used to scribble Heap::m_worldState
https://bugs.webkit.org/show_bug.cgi?id=199498
Follow-up after r247160. The value used to scribble should have the
conn bit set.
* heap/Heap.cpp:
(JSC::Heap::~Heap):
2019-07-05 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r247115.
Breaks lldbWebKitTester (and by extension, test-webkitpy)
Reverted changeset:
"[WHLSL] Standard library is too big to directly include in
WebCore"
https://bugs.webkit.org/show_bug.cgi?id=198186
https://trac.webkit.org/changeset/247115
2019-07-05 Tadeu Zagallo <tzagallo@apple.com>
Scribble Heap::m_worldState on destructor
https://bugs.webkit.org/show_bug.cgi?id=199498
Reviewed by Sam Weinig.
The worldState is dumped when we crash due to a failed checkConn, and
this will make it clear if the heap has already been destroyed.
* heap/Heap.cpp:
(JSC::Heap::~Heap):
2019-07-03 Sam Weinig <weinig@apple.com>
Adopt simple structured bindings in more places
https://bugs.webkit.org/show_bug.cgi?id=199247
Reviewed by Alex Christensen.
Replaces simple uses of std::tie() with structured bindings. Does not touch
uses of std::tie() that are not initial declarations, use std::ignore or in
case where the binding is captured by a lambda, as structured bindings don't
work for those cases yet.
* runtime/PromiseDeferredTimer.cpp:
(JSC::PromiseDeferredTimer::doWork):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::createSourceBufferFromValue):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyValidateFunc):
2019-07-03 Keith Miller <keith_miller@apple.com>
PACCage should first cage leaving PAC bits intact then authenticate
https://bugs.webkit.org/show_bug.cgi?id=199372
Reviewed by Saam Barati.
This ordering prevents someone from taking a signed pointer from
outside the gigacage and using it in a struct that expects a caged
pointer. Previously, the PACCaging just double checked that the PAC
bits were valid for the original pointer.
+---------------------------+
| | | |
| "PAC" | "base" | "offset" +----+
| | | | |
+---------------------------+ | Caging
| |
| |
| v
| +---------------------------+
| | | | |
| Bit Merge | 00000 | base | "offset" |
| | | | |
| +---------------------------+
| |
| |
v | Bit Merge
+---------------------------+ |
| | | | |
| "PAC" | base | "offset" +<--------+
| | | |
+---------------------------+
|
|
| Authenticate
|
v
+---------------------------+
| | | |
| Auth | base | "offset" |
| | | |
+---------------------------+
The above ascii art graph shows how the PACCage system works. The
key take away is that even if someone passes in a valid, signed
pointer outside the cage it will still fail to authenticate as the
"base" bits will change before authentication.
* assembler/MacroAssemblerARM64E.h:
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageConditionally):
* llint/LowLevelInterpreter64.asm:
2019-07-03 Paulo Matos <pmatos@igalia.com>
Refactoring of architectural Register Information
https://bugs.webkit.org/show_bug.cgi?id=198604
Reviewed by Keith Miller.
The goal of this patch is to centralize the register information per platform
but access it in a platform independent way. The patch as been implemented for all
known platforms: ARM64, ARMv7, MIPS, X86 and X86_64. Register information has
been centralized in an architecture per-file: each file is called assembler/<arch>Registers.h.
RegisterInfo.h is used as a forwarding header to choose which register information to load.
assembler/<arch>Assembler.h and jit/RegisterSet.cpp use this information in a platform
independent way.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::gprName): Use register names from register info file.
(JSC::ARM64Assembler::sprName): likewise.
(JSC::ARM64Assembler::fprName): likewise.
* assembler/ARM64Registers.h: Added.
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::gprName): Use register names from register info file.
(JSC::ARMv7Assembler::sprName): likewise.
(JSC::ARMv7Assembler::fprName): likewise.
* assembler/ARMv7Registers.h: Added.
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::gprName): Use register names from register info file.
(JSC::MIPSAssembler::sprName): likewise.
(JSC::MIPSAssembler::fprName): likewise.
* assembler/MIPSRegisters.h: Added.
* assembler/RegisterInfo.h: Added.
* assembler/X86Assembler.h:
(JSC::X86Assembler::gprName): Use register names from register info file.
(JSC::X86Assembler::sprName): likewise.
(JSC::X86Assembler::fprName): likewise.
* assembler/X86Registers.h: Added.
* assembler/X86_64Registers.h: Added.
* jit/GPRInfo.h: Fix typo in comment (s/basline/baseline).
* jit/RegisterSet.cpp:
(JSC::RegisterSet::reservedHardwareRegisters): Use register properties from register info file.
(JSC::RegisterSet::calleeSaveRegisters): likewise.
2019-07-02 Michael Saboff <msaboff@apple.com>
Exception from For..of loop destructured assignment eliminates TDZ checks in subsequent code
https://bugs.webkit.org/show_bug.cgi?id=199395
Reviewed by Filip Pizlo.
For destructuring assignmests, the assignment might throw a reference error if
the RHS cannot be coerced. The current bytecode generated for such assignments
optimizes out the TDZ check after the coercible check.
By saving the current state of the TDZ stack before processing the setting of
target destructured values and then restoring afterwards, we won't optimize out
later TDZ check(s).
A similar change of saving / restoring the TDZ stack where exceptions might
happen was done for for..in loops in change set r232219.
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue const):
2019-07-02 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r247041.
https://bugs.webkit.org/show_bug.cgi?id=199425
broke some iOS arm64e tests (Requested by keith_miller on
#webkit).
Reverted changeset:
"PACCage should first cage leaving PAC bits intact then
authenticate"
https://bugs.webkit.org/show_bug.cgi?id=199372
https://trac.webkit.org/changeset/247041
2019-07-02 Keith Miller <keith_miller@apple.com>
Frozen Arrays length assignment should throw in strict mode
https://bugs.webkit.org/show_bug.cgi?id=199365
Reviewed by Yusuke Suzuki.
* runtime/JSArray.cpp:
(JSC::JSArray::put):
2019-07-02 Paulo Matos <pmatos@linki.tools>
Fix typo in if/else block and remove dead assignment
https://bugs.webkit.org/show_bug.cgi?id=199352
Reviewed by Alexey Proskuryakov.
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPattern::dumpPattern): Fix typo in if/else block and remove dead assignment
2019-07-02 Keith Miller <keith_miller@apple.com>
PACCage should first cage leaving PAC bits intact then authenticate
https://bugs.webkit.org/show_bug.cgi?id=199372
Reviewed by Saam Barati.
This ordering prevents someone from taking a signed pointer from
outside the gigacage and using it in a struct that expects a caged
pointer. Previously, the PACCaging just double checked that the PAC
bits were valid for the original pointer.
+---------------------------+
| | | |
| "PAC" | "base" | "offset" +----+
| | | | |
+---------------------------+ | Caging
| |
| |
| v
| +---------------------------+
| | | | |
| Bit Merge | 00000 | base | "offset" |
| | | | |
| +---------------------------+
| |
| |
v | Bit Merge
+---------------------------+ |
| | | | |
| "PAC" | base | "offset" +<--------+
| | | |
+---------------------------+
|
|
| Authenticate
|
v
+---------------------------+
| | | |
| Auth | base | "offset" |
| | | |
+---------------------------+
The above ascii art graph shows how the PACCage system works. The
key take away is that even if someone passes in a valid, signed
pointer outside the cage it will still fail to authenticate as the
"base" bits will change before authentication.
* assembler/MacroAssemblerARM64E.h:
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageConditionally):
* llint/LowLevelInterpreter64.asm:
2019-07-01 Justin Michaud <justin_michaud@apple.com>
[Wasm-References] Disable references by default
https://bugs.webkit.org/show_bug.cgi?id=199390
Reviewed by Saam Barati.
* runtime/Options.h:
2019-07-01 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r246946.
Caused JSC test crashes on arm64
Reverted changeset:
"Add b3 macro lowering for CheckMul on arm64"
https://bugs.webkit.org/show_bug.cgi?id=199251
https://trac.webkit.org/changeset/246946
2019-06-28 Justin Michaud <justin_michaud@apple.com>
Add b3 macro lowering for CheckMul on arm64
https://bugs.webkit.org/show_bug.cgi?id=199251
Reviewed by Robin Morisset.
- Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
- Add a new opcode to air on arm64 for smull (multiplySignExtend32).
- Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits).
- 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark,
and no change on the no-constant benchmark.
Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
to completion.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::multiplySignExtend32):
* assembler/testmasm.cpp:
(JSC::testMul32SignExtend):
(JSC::run):
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testMulArgs32SignExtend):
(JSC::B3::testMulImm32SignExtend):
(JSC::B3::testMemoryFence):
(JSC::B3::testStoreFence):
(JSC::B3::testLoadFence):
(JSC::B3::testPinRegisters):
(JSC::B3::run):
2019-06-28 Konstantin Tokarev <annulen@yandex.ru>
Remove traces of ENABLE_ICONDATABASE remaining after its removal in 219733
https://bugs.webkit.org/show_bug.cgi?id=199317
Reviewed by Michael Catanzaro.
While IconDatabase and all code using it was removed,
ENABLE_ICONDATABASE still exists as build option and C++ macro.
* Configurations/FeatureDefines.xcconfig:
2019-06-27 Mark Lam <mark.lam@apple.com>
FTL keepAlive()'s patchpoint should also declare that it reads HeapRange::top().
https://bugs.webkit.org/show_bug.cgi?id=199291
Reviewed by Yusuke Suzuki and Filip Pizlo.
The sole purpose of keepAlive() is to communicate to B3 that an LValue
needs to be kept alive past the last opportunity for a GC. The only way
we can get a GC is via a function call. Hence, what keepAlive() really
needs to communicate is that the LValue needs to be kept alive past the
last function call. Function calls read and write HeapRange::top().
Currently, B3 does not shuffle writes. Hence, simply inserting the
keepAlive() after the calls that can GC is sufficient.
But to be strictly correct, keepAlive() should also declare that it reads
HeapRange::top(). This will guarantee that the keepAlive patchpoint won't
ever be moved before the function call should B3 gain the ability to shuffle
writes in the future.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::keepAlive):
2019-06-27 Beth Dakin <bdakin@apple.com>
Upstream use of MACCATALYST
https://bugs.webkit.org/show_bug.cgi?id=199245
rdar://problem/51687723
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* Configurations/JavaScriptCore.xcconfig:
* Configurations/SDKVariant.xcconfig:
2019-06-27 Saam Barati <sbarati@apple.com>
Make WEBGPU enabled only on Mojave and later.
Rubber-stamped by Myles C. Maxfield.
* Configurations/FeatureDefines.xcconfig:
2019-06-27 Don Olmstead <don.olmstead@sony.com>
[FTW] Build JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=199254
Reviewed by Brent Fulgham.
* PlatformFTW.cmake: Added.
2019-06-27 Konstantin Tokarev <annulen@yandex.ru>
Use JSC_GLIB_API_ENABLED instead of USE(GLIB) as a compile-time check for GLib JSC API
https://bugs.webkit.org/show_bug.cgi?id=199270
Reviewed by Michael Catanzaro.
This change allows building code with enabled USE(GLIB) but without
GLib JSC API.
* heap/Heap.cpp:
(JSC::Heap::releaseDelayedReleasedObjects):
* heap/Heap.h:
* heap/HeapInlines.h:
2019-06-27 Devin Rousso <drousso@apple.com>
Web Inspector: throw an error if console.count/console.countReset is called with an object that throws an error from toString
https://bugs.webkit.org/show_bug.cgi?id=199252
Reviewed by Joseph Pecoraro.
Parse the arguments passed to `console.count` and `console.countReset` before sending it to
the `ConsoleClient` so that an error can be thrown if the first argument doesn't `toString`
nicely (e.g. without throwing an error).
Generate call stacks for `console.countReset` to match other `console` methods. Also do this
for `console.time`, `console.timeLog`, and `console.timeEnd`. Limit the call stack to only
have the top frame, so no unnecessary/extra data is sent to the frontend (right now, only
the call location is displayed).
Rename `title` to `label` for `console.time`, `console.timeLog`, and `console.timeEnd` to
better match the spec.
* runtime/ConsoleClient.h:
* runtime/ConsoleObject.cpp:
(JSC::valueOrDefaultLabelString):
(JSC::consoleProtoFuncCount):
(JSC::consoleProtoFuncCountReset):
(JSC::consoleProtoFuncTime):
(JSC::consoleProtoFuncTimeLog):
(JSC::consoleProtoFuncTimeEnd):
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::count):
(Inspector::JSGlobalObjectConsoleClient::countReset):
(Inspector::JSGlobalObjectConsoleClient::time):
(Inspector::JSGlobalObjectConsoleClient::timeLog):
(Inspector::JSGlobalObjectConsoleClient::timeEnd):
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::startTiming):
(Inspector::InspectorConsoleAgent::logTiming):
(Inspector::InspectorConsoleAgent::stopTiming):
(Inspector::InspectorConsoleAgent::count):
(Inspector::InspectorConsoleAgent::countReset):
(Inspector::InspectorConsoleAgent::getCounterLabel): Deleted.
* inspector/ConsoleMessage.h:
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::ConsoleMessage):
Allow `ConsoleMessage`s to be created with both `ScriptArguments` and a `ScriptCallStack`.
2019-06-27 Fujii Hironori <Hironori.Fujii@sony.com>
[CMake] Bump cmake_minimum_required version to 3.10
https://bugs.webkit.org/show_bug.cgi?id=199181
Reviewed by Don Olmstead.
* CMakeLists.txt:
2019-06-26 Basuke Suzuki <Basuke.Suzuki@sony.com>
[RemoteInspector] Add address argument to listen for RemoteInspectorServer Socket implementation.
https://bugs.webkit.org/show_bug.cgi?id=199035
Reviewed by Ross Kirsling.
Added new argument `address` to start listening.
* inspector/remote/socket/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::start):
* inspector/remote/socket/RemoteInspectorServer.h:
* inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
(Inspector::Socket::listen):
* inspector/remote/socket/win/RemoteInspectorSocketWin.cpp:
(Inspector::Socket::listen):
2019-06-26 Keith Miller <keith_miller@apple.com>
speciesConstruct needs to throw if the result is a DataView
https://bugs.webkit.org/show_bug.cgi?id=199231
Reviewed by Mark Lam.
Previously, we only checked that the result was a
JSArrayBufferView, which can include DataViews. This is incorrect
as the result should be only be a TypedArray.
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
2019-06-26 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Implement console.countReset
https://bugs.webkit.org/show_bug.cgi?id=199200
Reviewed by Devin Rousso.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::countReset):
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::getCounterLabel):
(Inspector::InspectorConsoleAgent::count):
(Inspector::InspectorConsoleAgent::countReset):
* inspector/agents/InspectorConsoleAgent.h:
* runtime/ConsoleClient.h:
* runtime/ConsoleObject.cpp:
(JSC::ConsoleObject::finishCreation):
(JSC::consoleProtoFuncCountReset):
2019-06-26 Keith Miller <keith_miller@apple.com>
remove unneeded didBecomePrototype() calls
https://bugs.webkit.org/show_bug.cgi?id=199221
Reviewed by Saam Barati.
Since we now set didBecomePrototype in Structure::create we don't
need to set it expliticly in most of our finishCreation
methods. The only exception to this is object prototype, which we
set as the prototype of function prototype late (via
setPrototypeWithoutTransition).
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSJavaScriptCallFramePrototype::finishCreation):
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/AsyncFromSyncIteratorPrototype.cpp:
(JSC::AsyncFromSyncIteratorPrototype::finishCreation):
* runtime/AsyncFunctionPrototype.cpp:
(JSC::AsyncFunctionPrototype::finishCreation):
* runtime/AsyncGeneratorFunctionPrototype.cpp:
(JSC::AsyncGeneratorFunctionPrototype::finishCreation):
* runtime/AsyncGeneratorPrototype.cpp:
(JSC::AsyncGeneratorPrototype::finishCreation):
* runtime/AsyncIteratorPrototype.cpp:
(JSC::AsyncIteratorPrototype::finishCreation):
* runtime/GeneratorFunctionPrototype.cpp:
(JSC::GeneratorFunctionPrototype::finishCreation):
* runtime/GeneratorPrototype.cpp:
(JSC::GeneratorPrototype::finishCreation):
* runtime/IteratorPrototype.cpp:
(JSC::IteratorPrototype::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
* 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/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
* runtime/WeakObjectRefPrototype.cpp:
(JSC::WeakObjectRefPrototype::finishCreation):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
2019-06-25 Keith Miller <keith_miller@apple.com>
Structure::create should call didBecomePrototype()
https://bugs.webkit.org/show_bug.cgi?id=196315
Reviewed by Filip Pizlo.
Structure::create should also assert that the indexing type makes sense
for the prototype being used.
* runtime/JSObject.h:
* runtime/Structure.cpp:
(JSC::Structure::isValidPrototype):
(JSC::Structure::changePrototypeTransition):
* runtime/Structure.h:
(JSC::Structure::create): Deleted.
* runtime/StructureInlines.h:
(JSC::Structure::create):
(JSC::Structure::setPrototypeWithoutTransition):
2019-06-25 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Implement console.timeLog
https://bugs.webkit.org/show_bug.cgi?id=199184
Reviewed by Devin Rousso.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::timeLog):
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::logTiming):
(Inspector::InspectorConsoleAgent::stopTiming):
* inspector/agents/InspectorConsoleAgent.h:
* runtime/ConsoleClient.h:
* runtime/ConsoleObject.cpp:
(JSC::ConsoleObject::finishCreation):
(JSC::consoleProtoFuncTimeLog):
2019-06-25 Michael Catanzaro <mcatanzaro@igalia.com>
REGRESSION(r245586): static assertion failed: Match result and EncodedMatchResult should be the same size
https://bugs.webkit.org/show_bug.cgi?id=198518
Reviewed by Keith Miller.
r245586 made some bad assumptions about the size of size_t, which we can solve using the
CPU(ADDRESS32) guard that I didn't know about.
This solution was developed by Mark Lam and Keith Miller. I'm just preparing the patch.
* runtime/MatchResult.h:
2019-06-24 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r246714.
https://bugs.webkit.org/show_bug.cgi?id=199179
revert to do patch in a different way. (Requested by keith_mi_
on #webkit).
Reverted changeset:
"All prototypes should call didBecomePrototype()"
https://bugs.webkit.org/show_bug.cgi?id=196315
https://trac.webkit.org/changeset/246714
2019-06-24 Alexey Shvayka <shvaikalesh@gmail.com>
Add Array.prototype.{flat,flatMap} to unscopables
https://bugs.webkit.org/show_bug.cgi?id=194322
Reviewed by Keith Miller.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
2019-06-24 Mark Lam <mark.lam@apple.com>
ArraySlice needs to keep the source array alive.
https://bugs.webkit.org/show_bug.cgi?id=197374
<rdar://problem/50304429>
Reviewed by Michael Saboff and Filip Pizlo.
The implementation of the FTL ArraySlice intrinsics may GC while allocating the
result array and its butterfly. Previously, ArraySlice already keeps the source
butterfly alive in order to copy from it to the new butterfly after the allocation.
Unfortunately, this is not enough. We also need to keep the source array alive
so that GC will scan the values in the butterfly as well. Note: the butterfly
does not have a visitChildren() method to do this scan. It's the parent object's
responsibility to do the scanning.
This patch fixes this by introducing a keepAlive() utility method, and we use it
to keep the source array alive while allocating the result array and butterfly.
keepAlive() works by using a patchpoint to communicate to B3 that a value (the
source array in this case) is still in use. It also uses a fence to keep B3 from
relocating the patchpoint, which may defeat the fix.
For the DFG's SpeculativeJIT::compileArraySlice(), we may have lucked out and the
source array cell is kept alive. This patch makes it explicit that we should
keep its cell alive till after the result array has been allocated.
For the Baseline JIT and LLInt, we use the arrayProtoFuncSlice() runtime function
and there is no issue because the source array (in "thisObj") is in the element
copying loop that follows the allocation of the result array. However, for
documentation purposes, this patch adds a call to HeapCell::use() to indicate that
the source array need to kept alive at least until after the allocation of the
result array.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArraySlice):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::keepAlive):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSlice):
2019-06-22 Robin Morisset <rmorisset@apple.com> and Yusuke Suzuki <ysuzuki@apple.com>
All prototypes should call didBecomePrototype()
https://bugs.webkit.org/show_bug.cgi?id=196315
Reviewed by Saam Barati.
Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
create structures with invalid prototypes.
It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
* runtime/BigIntPrototype.cpp:
(JSC::BigIntPrototype::finishCreation):
* runtime/BooleanPrototype.cpp:
(JSC::BooleanPrototype::finishCreation):
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototype::finishCreation):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::finishCreation):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::finishCreation):
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototype::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSDataViewPrototype::finishCreation):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::createConsoleProperty):
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
* runtime/Structure.cpp:
(JSC::Structure::isValidPrototype):
(JSC::Structure::changePrototypeTransition):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setPrototypeWithoutTransition):
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
(JSC::WebAssemblyCompileErrorPrototype::finishCreation):
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::WebAssemblyInstancePrototype::finishCreation):
* wasm/js/WebAssemblyLinkErrorPrototype.cpp:
(JSC::WebAssemblyLinkErrorPrototype::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::WebAssemblyMemoryPrototype::finishCreation):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::WebAssemblyModulePrototype::finishCreation):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::WebAssemblyPrototype::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
(JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::WebAssemblyTablePrototype::finishCreation):
2019-06-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Strict, Sloppy and Arrow functions should have different classInfo
https://bugs.webkit.org/show_bug.cgi?id=197631
Reviewed by Saam Barati.
If a constructor inherits a builtin class, it creates a Structure which is subclassing the builtin class.
This is done by using InternalFunction::createSubclassStructure. But to accelerate the common cases, we
cache the created structure in InternalFunctionAllocationProfile. Whether the cache is valid is checked
by comparing classInfo of the cached structure and the given base structure. This implicitly assume that
each builtin class's InternalFunction creates an instance based on one structure.
However, Function constructor is an exception: Function constructor creates an instance which has different
structures based on a parameter. If a strict code is given (e.g. "'use strict'"), it creates a function
instance with strict function structure.
As a result, InternalFunctionAllocationProfile incorrectly caches the structure. Consider the following code.
class A extends Function { };
let a = new A("'use strict'");
let b = new A("");
While `a` and `b` should have different structures, `A` caches the structure for `a`, and reuse it even the given
code is not a strict code. This is problematic: We are separating structures of strict, sloppy, and arrow functions
because they have different properties. However, in the above case, a and b have the same structure while they have
different properties. So it causes incorrect structure-based caching in JSC. One of the example is HasOwnPropertyCache.
In this patch, we introduce JSStrictFunction, JSSloppyFunction, and JSArrowFunction classes and classInfos. This design
works well and already partially accepted for JSGeneratorFunction, JSAsyncGeneratorFunction, and JSAsyncFunction. Each
structure now has a different classInfo so that InternalFunctionAllocationProfile correctly caches and invalidates the
cached one based on the classInfo. Since we already have different structures for these instances, and DFG and FTL
optimizations are based on JSFunctionType (not classInfo), introducing these three classInfo do not break the optimization.
Note that structures on ArrayConstructor does not cause the same problem. It only uses Undecided indexing typed array
structure in InternalFunctionAllocationProfile, and once haveABadTime happens, it clears InternalFunctionAllocationProfile.
* runtime/JSAsyncFunction.h: This subspaceFor is not necessary since it is defined in JSFunction. And we already ensure that
sizeof(JSAsyncFunction) == sizeof(JSFunction).
* runtime/JSAsyncGeneratorFunction.cpp:
* runtime/JSAsyncGeneratorFunction.h: Ditto.
* runtime/JSFunction.cpp:
* runtime/JSFunction.h:
* runtime/JSGeneratorFunction.h: Ditto.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2019-06-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] ClassExpr should not store result in the middle of evaluation
https://bugs.webkit.org/show_bug.cgi?id=199106
Reviewed by Tadeu Zagallo.
Let's consider the case,
let a = class A {
static get[a=0x12345678]() {
}
};
When evaluating `class A` expression, we should not use the local register for `let a`
until we finally store it to that register. Otherwise, `a=0x12345678` will override it.
Out BytecodeGenerator does that this by using tempDestination and finalDestination, but
we did not do that in ClassExprNode.
This patch leverages tempDestination and finalDestination to store `class A` result finally,
while we attempt to reduce mov.
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
2019-06-21 Sihui Liu <sihui_liu@apple.com>
openDatabase should return an empty object when WebSQL is disabled
https://bugs.webkit.org/show_bug.cgi?id=198805
Reviewed by Geoffrey Garen.
* runtime/JSFunction.cpp:
(JSC::JSFunction::createFunctionThatMasqueradesAsUndefined):
* runtime/JSFunction.h:
2019-06-21 Alexey Shvayka <shvaikalesh@gmail.com>
Remove extra check in RegExp @matchSlow
https://bugs.webkit.org/show_bug.cgi?id=198846
Reviewed by Joseph Pecoraro.
Type of RegExp `exec` result is already asserted in @regExpExec.
* builtins/RegExpPrototype.js:
(globalPrivate.matchSlow): Remove isObject check.
2019-06-20 Justin Michaud <justin_michaud@apple.com>
[WASM-References] Add extra tests for Wasm references + fix element parsing and subtyping bugs
https://bugs.webkit.org/show_bug.cgi?id=199044
Reviewed by Saam Barati.
Fix parsing table indices from the element section. The byte that we previously read as the table index actually tells us how to parse the table index.
Fix some areas where we got the isSubtype check wrong, causing funcrefs to not be considred anyrefs.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::unify):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseElement):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::unify):
2019-06-18 Darin Adler <darin@apple.com>
Tidy up the remaining bits of the AtomicString to AtomString rename
https://bugs.webkit.org/show_bug.cgi?id=198990
Reviewed by Michael Catanzaro.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Use flagIsAtom.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Ditto.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile): Ditto.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty): Ditto.
(JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent): Ditto.
2019-06-19 Alexey Shvayka <shvaikalesh@gmail.com>
Optimize `resolve` method lookup in Promise static methods
https://bugs.webkit.org/show_bug.cgi?id=198864
Reviewed by Yusuke Suzuki.
Lookup `resolve` method only once in Promise.{all,allSettled,race}.
(https://github.com/tc39/ecma262/pull/1506)
Already implemented in V8.
* builtins/PromiseConstructor.js:
2019-06-19 Tadeu Zagallo <tzagallo@apple.com>
Some of the ASSERTs in CachedTypes.cpp should be RELEASE_ASSERTs
https://bugs.webkit.org/show_bug.cgi?id=199030
Reviewed by Mark Lam.
These assertions represent strong assumptions that the cache makes so
it's not safe to keep executing if they fail.
* runtime/CachedTypes.cpp:
(JSC::Encoder::malloc):
(JSC::Encoder::Page::alignEnd):
(JSC::Decoder::ptrForOffsetFromBase):
(JSC::Decoder::handleForEnvironment const):
(JSC::Decoder::setHandleForEnvironment):
(JSC::CachedPtr::get const):
(JSC::CachedOptional::encode):
(JSC::CachedOptional::decodeAsPtr const): Deleted.
2019-06-19 Adrian Perez de Castro <aperez@igalia.com>
[WPE][GTK] Fix build with unified sources disabled
https://bugs.webkit.org/show_bug.cgi?id=198752
Reviewed by Michael Catanzaro.
* runtime/WeakObjectRefConstructor.h: Add missing inclusion of InternalFunction.h
and forward declaration of WeakObjectRefPrototype.
* wasm/js/WebAssemblyFunction.cpp: Add missing inclusion of JSWebAssemblyHelpers.h
2019-06-19 Justin Michaud <justin_michaud@apple.com>
[WASM-References] Rename anyfunc to funcref
https://bugs.webkit.org/show_bug.cgi?id=198983
Reviewed by Yusuke Suzuki.
Anyfunc should become funcref since it was renamed in the spec. We should also support the string 'anyfunc' in the table constructor since this is
the only non-binary-format place where it is exposed to users.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::gFuncref):
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::emitCCall):
(JSC::Wasm::AirIRGenerator::moveOpForValueType):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::addLocal):
(JSC::Wasm::AirIRGenerator::addConstant):
(JSC::Wasm::AirIRGenerator::addRefFunc):
(JSC::Wasm::AirIRGenerator::addReturn):
(JSC::Wasm::AirIRGenerator::gAnyfunc): Deleted.
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConventionAir::marshallArgument const):
(JSC::Wasm::CallingConventionAir::setupCall const):
* wasm/WasmExceptionType.h:
* wasm/WasmFormat.h:
(JSC::Wasm::isValueType):
(JSC::Wasm::isSubtype):
(JSC::Wasm::TableInformation::wasmType const):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseTableHelper):
(JSC::Wasm::SectionParser::parseElement):
(JSC::Wasm::SectionParser::parseInitExpr):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addRefFunc):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
* wasm/wasm.json:
2019-06-19 Fujii Hironori <Hironori.Fujii@sony.com>
[CMake][Win] CombinedDomains.json is generated twice in JavaScriptCore_CopyPrivateHeaders and JavaScriptCore projects
https://bugs.webkit.org/show_bug.cgi?id=198853
Reviewed by Don Olmstead.
JavaScriptCore_CopyPrivateHeaders target needs to have a direct or
indirect dependency of JavaScriptCore target for CMake Visual
Studio generator to eliminate duplicated custom commands.
* CMakeLists.txt: Added JavaScriptCore as a dependency of JavaScriptCore_CopyPrivateHeaders.
2019-06-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSLock should be WebThread aware
https://bugs.webkit.org/show_bug.cgi?id=198911
Reviewed by Geoffrey Garen.
Since WebKitLegacy content rendering is done in WebThread instead of the main thread in iOS, user of WebKitLegacy (e.g. UIWebView) needs
to grab the WebThread lock (which is a recursive lock) in the main thread when touching the WebKitLegacy content.
But, WebKitLegacy can expose JSContext for the web view. And we can interact with the JS content through JavaScriptCore APIs. However,
since WebThread is a concept in WebCore, JavaScriptCore APIs do not grab the WebThread lock. As a result, WebKitLegacy web content can be
modified from the main thread without grabbing the WebThread lock through JavaScriptCore APIs.
This patch makes JSC aware of WebThread: JSLock grabs the WebThread lock before grabbing JS's lock. While this seems layering violation,
we already have many USE(WEB_THREAD) and WebThread aware code in WTF. Eventually, we should move WebThread code from WebCore to WTF since
JSC and WTF need to be aware of WebThread. But, for now, we just use the function pointer exposed by WebCore.
Since both JSLock and the WebThread lock are recursive locks, nested locking is totally OK. The possible problem is the order of locking.
We ensure that we always grab locks in (1) the WebThread lock and (2) JSLock order.
In JSLock, we take the WebThread lock, but we do not unlock it. This is how we use the WebThread lock: the WebThread lock is released
automatically when RunLoop finishes the current cycle, and in WebKitLegacy, we do not call unlocking function of the WebThread lock except
for some edge cases.
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine isWebThreadAware]):
* API/JSVirtualMachineInternal.h:
* runtime/JSLock.cpp:
(JSC::JSLockHolder::JSLockHolder):
(JSC::JSLock::lock):
(JSC::JSLockHolder::init): Deleted.
* runtime/JSLock.h:
(JSC::JSLock::makeWebThreadAware):
(JSC::JSLock::isWebThreadAware const):
2019-06-18 Justin Michaud <justin_michaud@apple.com>
[WASM-References] Add support for Table.size, grow and fill instructions
https://bugs.webkit.org/show_bug.cgi?id=198761
Reviewed by Yusuke Suzuki.
Add support for Table.size, grow and fill instructions. This also required
adding support for two-byte opcodes to the ops generator.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::gAnyref):
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::addTableSize):
(JSC::Wasm::AirIRGenerator::addTableGrow):
(JSC::Wasm::AirIRGenerator::addTableFill):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addTableSize):
(JSC::Wasm::B3IRGenerator::addTableGrow):
(JSC::Wasm::B3IRGenerator::addTableFill):
* wasm/WasmExceptionType.h:
* wasm/WasmFormat.h:
(JSC::Wasm::TableInformation::wasmType const):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmInstance.cpp:
(JSC::Wasm::doWasmTableGrow):
(JSC::Wasm::doWasmTableFill):
* wasm/WasmInstance.h:
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::grow):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addTableSize):
(JSC::Wasm::Validate::addTableGrow):
(JSC::Wasm::Validate::addTableFill):
* wasm/generateWasmOpsHeader.py:
(opcodeMacroizer):
(ExtTableOpType):
* wasm/wasm.json:
2019-06-18 Keith Miller <keith_miller@apple.com>
Unreviewed, fix signature of currentWeakRefVersion to return an uintptr_t.
* runtime/VM.h:
(JSC::VM::currentWeakRefVersion const):
2019-06-18 Justin Michaud <justin_michaud@apple.com>
[WASM-References] Add support for multiple tables
https://bugs.webkit.org/show_bug.cgi?id=198760
Reviewed by Saam Barati.
Support multiple wasm tables. We turn tableInformation into a tables array, and update all of the
existing users to give a table index. The array of Tables in Wasm::Instance is hung off the tail
to make it easier to use from jit code.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::addTableGet):
(JSC::Wasm::AirIRGenerator::addTableSet):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::addTableGet):
(JSC::Wasm::B3IRGenerator::addTableSet):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmExceptionType.h:
* wasm/WasmFormat.h:
(JSC::Wasm::Element::Element):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::Instance):
(JSC::Wasm::Instance::create):
(JSC::Wasm::Instance::extraMemoryAllocated const):
(JSC::Wasm::Instance::table):
(JSC::Wasm::Instance::setTable):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::updateCachedMemory):
(JSC::Wasm::Instance::offsetOfGlobals):
(JSC::Wasm::Instance::offsetOfTablePtr):
(JSC::Wasm::Instance::allocationSize):
(JSC::Wasm::Instance::table): Deleted.
(JSC::Wasm::Instance::setTable): Deleted.
(JSC::Wasm::Instance::offsetOfTable): Deleted.
* wasm/WasmModuleInformation.h:
(JSC::Wasm::ModuleInformation::tableCount const):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseImport):
(JSC::Wasm::SectionParser::parseTableHelper):
(JSC::Wasm::SectionParser::parseTable):
(JSC::Wasm::SectionParser::parseElement):
* wasm/WasmTable.h:
(JSC::Wasm::Table::owner const):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addTableGet):
(JSC::Wasm::Validate::addTableSet):
(JSC::Wasm::Validate::addCallIndirect):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/wasm.json:
2019-06-18 Alexey Shvayka <shvaikalesh@gmail.com>
[ESNExt] String.prototype.matchAll
https://bugs.webkit.org/show_bug.cgi?id=186694
Reviewed by Yusuke Suzuki.
Implement String.prototype.matchAll.
(https://tc39.es/ecma262/#sec-string.prototype.matchall)
Also rename @globalPrivate @constructor functions and C++ variables holding them.
Shipping in Chrome since version 73.
Shipping in Firefox since version 67.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/wkbuiltins/builtins_generate_combined_header.py:
(get_var_name):
(generate_section_for_global_private_code_name_macro):
* Sources.txt:
* builtins/ArrayPrototype.js:
(globalPrivate.ArrayIterator):
(values):
(keys):
(entries):
(globalPrivate.createArrayIterator): Deleted.
* builtins/AsyncFromSyncIteratorPrototype.js:
(globalPrivate.createAsyncFromSyncIterator):
(globalPrivate.AsyncFromSyncIterator):
(globalPrivate.AsyncFromSyncIteratorConstructor): Deleted.
* builtins/BuiltinNames.h:
* builtins/MapPrototype.js:
(globalPrivate.MapIterator):
(values):
(keys):
(entries):
(globalPrivate.createMapIterator): Deleted.
* builtins/RegExpPrototype.js:
(globalPrivate.RegExpStringIterator):
(overriddenName.string_appeared_here.matchAll):
* builtins/RegExpStringIteratorPrototype.js: Added.
(next):
* builtins/SetPrototype.js:
(globalPrivate.SetIterator):
(values):
(entries):
(globalPrivate.createSetIterator): Deleted.
* builtins/StringPrototype.js:
(matchAll):
* builtins/TypedArrayPrototype.js:
(values):
(keys):
(entries):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
* runtime/RegExpStringIteratorPrototype.cpp: Added.
(JSC::RegExpStringIteratorPrototype::finishCreation):
* runtime/RegExpStringIteratorPrototype.h: Added.
* runtime/StringPrototype.cpp:
2019-06-18 Keith Miller <keith_miller@apple.com>
Add support for WeakRef
https://bugs.webkit.org/show_bug.cgi?id=198710
Reviewed by Yusuke Suzuki.
Add support for WeakRefs which are now at stage 3
(https://tc39.es/proposal-weakrefs). This patch doesn't add
support for FinalizationGroups, which I'll add in another patch.
Some other things of interest. Per the spec, we cannot collect a
weak refs target unless it has not been dereffed (or created) in
the current microtask turn. i.e. WeakRefs are only allowed to be
collected at the end of a drain of the Microtask queue. My
understanding for this behavior is to reduce implementation
dependence on specific GC behavior in a given browser.
We track if a WeakRef is retaining its target by using a version
number on each WeakRef as well as on the VM. Whenever a WeakRef is
derefed we update its version number to match the VM's then
WriteBarrier ourselves. During marking if the VM and the WeakRef
have the same version number, the target is visited.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionReleaseWeakRefs):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSWeakObjectRef.cpp: Added.
(JSC::JSWeakObjectRef::finishCreation):
(JSC::JSWeakObjectRef::visitChildren):
(JSC::JSWeakObjectRef::finalizeUnconditionally):
(JSC::JSWeakObjectRef::toStringName):
* runtime/JSWeakObjectRef.h: Added.
* runtime/VM.cpp:
(JSC::VM::drainMicrotasks):
* runtime/VM.h:
(JSC::VM::setOnEachMicrotaskTick):
(JSC::VM::finalizeSynchronousJSExecution):
(JSC::VM::currentWeakRefVersion const):
* runtime/WeakObjectRefConstructor.cpp: Added.
(JSC::WeakObjectRefConstructor::finishCreation):
(JSC::WeakObjectRefConstructor::WeakObjectRefConstructor):
(JSC::callWeakRef):
(JSC::constructWeakRef):
* runtime/WeakObjectRefConstructor.h: Added.
(JSC::WeakObjectRefConstructor::create):
(JSC::WeakObjectRefConstructor::createStructure):
* runtime/WeakObjectRefPrototype.cpp: Added.
(JSC::WeakObjectRefPrototype::finishCreation):
(JSC::getWeakRef):
(JSC::protoFuncWeakRefDeref):
* runtime/WeakObjectRefPrototype.h: Added.
2019-06-18 Tadeu Zagallo <tzagallo@apple.com>
Add missing mutator fence in compileNewFunction
https://bugs.webkit.org/show_bug.cgi?id=198849
<rdar://problem/51733890>
Reviewed by Saam Barati.
Follow-up after r246553. Saam pointed out that we still need a mutator
fence before allocating the FunctionRareData, since the allocation
might trigger a slow path call.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
2019-06-18 Tadeu Zagallo <tzagallo@apple.com>
DFG code should not reify the names of builtin functions with private names
https://bugs.webkit.org/show_bug.cgi?id=198849
<rdar://problem/51733890>
Reviewed by Filip Pizlo.
Builtin functions that have a private name call setHasReifiedName from finishCreation.
When compiled with DFG and FTL, that does not get called and the function ends up reifying
its name. In order to fix that, we initialize FunctionRareData and set m_hasReifiedName to
true from compileNewFunction in both DFG and FTL.
* bytecode/InternalFunctionAllocationProfile.h:
(JSC::InternalFunctionAllocationProfile::offsetOfStructure):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfileWithPrototype::offsetOfPrototype):
* bytecode/UnlinkedFunctionExecutable.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
* runtime/FunctionExecutable.h:
* runtime/FunctionRareData.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::finishCreation):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::isAnonymousBuiltinFunction const):
2019-06-18 Keith Miller <keith_miller@apple.com>
MaybeParseAsGeneratorForScope sometimes loses track of its scope ref
https://bugs.webkit.org/show_bug.cgi?id=198969
<rdar://problem/51620714>
Reviewed by Tadeu Zagallo.
Sometimes if the parser has enough nested scopes
MaybeParseAsGeneratorForScope can lose track of the ScopeRef it
should be tracking. This is because the parser sometimes relocates
its ScopeRefs. To fix this MaybeParseAsGeneratorForScope should
hold the scope ref it's watching.
* parser/Parser.cpp:
(JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope):
(JSC::Scope::MaybeParseAsGeneratorForScope::~MaybeParseAsGeneratorForScope):
2019-06-17 Justin Michaud <justin_michaud@apple.com>
Validate that table element type is funcref if using an element section
https://bugs.webkit.org/show_bug.cgi?id=198910
Reviewed by Yusuke Suzuki.
Add missing validation when attempting to add an element section to an anyref table.
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseElement):
2019-06-17 Tadeu Zagallo <tzagallo@apple.com>
Concurrent GC should check the conn before starting a new collection cycle
https://bugs.webkit.org/show_bug.cgi?id=198913
<rdar://problem/49515149>
Reviewed by Filip Pizlo.
Heap::requestCollection tries to steal the conn as an optimization to avoid waking up the collector
thread if it's idle. We determine if the collector is idle by ensuring that there are no pending collections
and that the current GC phase is NotRunning. However, that's not safe immediately after the concurrent
GC has finished processing the last pending request. The collector thread will runEndPhase and immediately
start runNotRunningPhase, without checking if it still has the conn. If the mutator has stolen the conn in
the mean time, this will lead to both threads collecting concurrently, and eventually we'll crash in checkConn,
since the collector is running but doesn't have the conn anymore.
To solve this, we check if we still have the conn after holding the lock in runNotRunningPhase, in case the mutator
has stolen the conn. Ideally, we wouldn't let the mutator steal the conn in the first place, but that doesn't seem
trivial to determine.
* heap/Heap.cpp:
(JSC::Heap::runNotRunningPhase):
2019-06-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Introduce DisposableCallSiteIndex to enforce type-safety
https://bugs.webkit.org/show_bug.cgi?id=197378
Reviewed by Saam Barati.
Some of CallSiteIndex are disposable. This is because some of CallSiteIndex are allocated and freed at runtime (not DFG/FTL compile time).
The example is CallSiteIndex for exception handler in GCAwareJITStubRoutineWithExceptionHandler. If we do not allocate and free CallSiteIndex,
we will create a new CallSiteIndex continuously and leak memory.
The other CallSiteIndex are not simply disposable because the ownership model is not unique one. They can be shared between multiple clients.
But not disposing them is OK because they are static one: they are allocated when compiling DFG/FTL, and we do not allocate such CallSiteIndex
at runtime.
To make this difference explicit and avoid disposing non-disposable CallSiteIndex accidentally, we introduce DisposableCallSiteIndex type, and
enforce type-safety to some degree.
We also correctly update the DisposableCallSiteIndex => CodeOrigin table when we are reusing the previously used DisposableCallSiteIndex.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
(JSC::CodeBlock::removeExceptionHandlerForCallSite):
* bytecode/CodeBlock.h:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::callSiteIndexForExceptionHandling): Deleted.
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::addUniqueCallSiteIndex):
(JSC::DFG::CommonData::addDisposableCallSiteIndex):
(JSC::DFG::CommonData::removeDisposableCallSiteIndex):
(JSC::DFG::CommonData::removeCallSiteIndex): Deleted.
* dfg/DFGCommonData.h:
* interpreter/CallFrame.h:
(JSC::DisposableCallSiteIndex::DisposableCallSiteIndex):
(JSC::DisposableCallSiteIndex::fromCallSiteIndex):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
(JSC::createJITStubRoutine):
* jit/GCAwareJITStubRoutine.h:
* jit/JITInlineCacheGenerator.h:
2019-06-17 Justin Michaud <justin_michaud@apple.com>
[WASM-References] Add support for Funcref in parameters and return types
https://bugs.webkit.org/show_bug.cgi?id=198157
Reviewed by Yusuke Suzuki.
Add support for funcref in parameters, globals, and in table.get/set. When converting a JSValue to
a funcref (nee anyfunc), we first make sure it is an exported wasm function or null.
We also add support for Ref.func. Anywhere a Ref.func is used, (statically) we construct a JS wrapper
for it so that we never need to construct JSValues when handling references. This should make threads
easier to implement.
Finally, we add some missing bounds checks for table.get/set.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::moveOpForValueType):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::addLocal):
(JSC::Wasm::AirIRGenerator::addConstant):
(JSC::Wasm::AirIRGenerator::addRefFunc):
(JSC::Wasm::AirIRGenerator::addTableSet):
(JSC::Wasm::AirIRGenerator::setGlobal):
(JSC::Wasm::AirIRGenerator::addReturn):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addLocal):
(JSC::Wasm::B3IRGenerator::addTableSet):
(JSC::Wasm::B3IRGenerator::addRefFunc):
(JSC::Wasm::B3IRGenerator::setGlobal):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::compileFunctions):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConventionAir::marshallArgument const):
(JSC::Wasm::CallingConventionAir::setupCall const):
* wasm/WasmExceptionType.h:
* wasm/WasmFormat.h:
(JSC::Wasm::isValueType):
(JSC::Wasm::isSubtype):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::Instance):
(JSC::Wasm::Instance::getFunctionWrapper const):
(JSC::Wasm::Instance::setFunctionWrapper):
* wasm/WasmInstance.h:
* wasm/WasmModuleInformation.h:
(JSC::Wasm::ModuleInformation::referencedFunctions const):
(JSC::Wasm::ModuleInformation::addReferencedFunction const):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseGlobal):
(JSC::Wasm::SectionParser::parseInitExpr):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addTableGet):
(JSC::Wasm::Validate::addTableSet):
(JSC::Wasm::Validate::addRefIsNull):
(JSC::Wasm::Validate::addRefFunc):
(JSC::Wasm::Validate::setLocal):
(JSC::Wasm::Validate::addCall):
(JSC::Wasm::Validate::addCallIndirect):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::isWebAssemblyHostFunction):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::createJSWebAssemblyRuntimeError):
* wasm/js/JSWebAssemblyRuntimeError.h:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::handleBadI64Use):
(JSC::Wasm::wasmToJS):
(JSC::Wasm::emitWasmToJSException):
* wasm/js/WasmToJS.h:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/wasm.json:
2019-06-16 Darin Adler <darin@apple.com>
Rename AtomicString to AtomString
https://bugs.webkit.org/show_bug.cgi?id=195276
Reviewed by Michael Catanzaro.
* many files: Let do-webcore-rename do the renaming.
2019-06-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Grown region of WasmTable should be initialized with null
https://bugs.webkit.org/show_bug.cgi?id=198903
Reviewed by Saam Barati.
Grown region of Wasmtable is now empty. We should initialize it with null.
We also rename Wasm::Table::visitChildren to Wasm::Table::visitAggregate to
align to the naming convention.
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::grow):
(JSC::Wasm::Table::visitAggregate):
(JSC::Wasm::Table::visitChildren): Deleted.
* wasm/WasmTable.h:
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::visitChildren):
2019-06-14 Keith Miller <keith_miller@apple.com>
Restore PAC based cage.
https://bugs.webkit.org/show_bug.cgi?id=198872
Rubber-stamped by Saam Barati.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::bitFieldInsert64):
* assembler/MacroAssemblerARM64E.h:
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
(JSC::run):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
(JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::caged):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageWithoutUntagging):
(JSC::AssemblyHelpers::cageConditionally):
(JSC::AssemblyHelpers::cage): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/instructions.rb:
* offlineasm/registers.rb:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2019-06-13 Yusuke Suzuki <ysuzuki@apple.com>
Yarr bytecode compilation failure should be gracefully handled
https://bugs.webkit.org/show_bug.cgi?id=198700
Reviewed by Michael Saboff.
Currently, we assume that Yarr bytecode compilation does not fail. But in fact it can fail.
We should gracefully handle this failure as a runtime error, as we did for parse errors in [1].
We also harden Yarr's consumed character calculation by using Checked.
[1]: https://bugs.webkit.org/show_bug.cgi?id=185755
* inspector/ContentSearchUtilities.cpp:
(Inspector::ContentSearchUtilities::findMagicComment):
* runtime/RegExp.cpp:
(JSC::RegExp::byteCodeCompileIfNecessary):
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* runtime/RegExpInlines.h:
(JSC::RegExp::matchInline):
* yarr/YarrErrorCode.cpp:
(JSC::Yarr::errorMessage):
(JSC::Yarr::errorToThrow):
* yarr/YarrErrorCode.h:
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::ByteCompiler):
(JSC::Yarr::ByteCompiler::compile):
(JSC::Yarr::ByteCompiler::atomCharacterClass):
(JSC::Yarr::ByteCompiler::atomBackReference):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
(JSC::Yarr::ByteCompiler::popParenthesesStack):
(JSC::Yarr::ByteCompiler::closeAlternative):
(JSC::Yarr::ByteCompiler::closeBodyAlternative):
(JSC::Yarr::ByteCompiler::alternativeBodyDisjunction):
(JSC::Yarr::ByteCompiler::alternativeDisjunction):
(JSC::Yarr::ByteCompiler::emitDisjunction):
2019-06-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call
https://bugs.webkit.org/show_bug.cgi?id=198770
Reviewed by Saam Barati.
Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls
are the following.
if (callee == patchableCallee) {
restore callee saves for tail call
prepare for tail call
jump to the target function
}
restore callee saves for slow path
call the slow path function
And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub
patches the above `if` statement with the jump to the stub.
jump to the polymorphic call stub
This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result,
"restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is
correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves.
This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled
in that path.
This patch does that skips after restoring callee saves.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setUpCall):
(JSC::CallLinkInfo::calleeGPR):
(JSC::CallLinkInfo::setCalleeGPR): Deleted.
* jit/Repatch.cpp:
(JSC::revertCall):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
* jit/Repatch.h:
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
2019-06-12 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r246322.
https://bugs.webkit.org/show_bug.cgi?id=198796
"It's a huge page load regression on iOS" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"Roll out PAC cage"
https://bugs.webkit.org/show_bug.cgi?id=198726
https://trac.webkit.org/changeset/246322
2019-06-11 Alexey Shvayka <shvaikalesh@gmail.com>
JSC should throw if proxy set returns falsish in strict mode context
https://bugs.webkit.org/show_bug.cgi?id=177398
Reviewed by Yusuke Suzuki.
Throw TypeError exception if Proxy's `set` trap returns falsy value.
(step 6.c of https://tc39.es/ecma262/#sec-putvalue)
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::put):
(JSC::ProxyObject::putByIndexCommon):
* runtime/ProxyObject.h:
2019-06-11 Alexey Shvayka <shvaikalesh@gmail.com>
Error message for non-callable Proxy `construct` trap is misleading
https://bugs.webkit.org/show_bug.cgi?id=198637
Reviewed by Saam Barati.
Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]].
* runtime/ProxyObject.cpp:
(JSC::performProxyConstruct): Tweak error message.
2019-06-10 Tadeu Zagallo <tzagallo@apple.com>
AI BitURShift's result should not be unsigned
https://bugs.webkit.org/show_bug.cgi?id=198689
<rdar://problem/51550063>
Reviewed by Saam Barati.
Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it.
This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but
get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber,
all we have to do is store the result as a signed int32.
* dfg/DFGAbstractInterpreterInlines.h:
2019-06-11 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed build warning fixes
Silence -Wreturn-type warning
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::tryCreate):
2019-06-11 Saam Barati <sbarati@apple.com>
Roll out PAC cage
https://bugs.webkit.org/show_bug.cgi?id=198726
Reviewed by Keith Miller.
This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622.
The resulting state we're in is we have Gigacage enabled on arm64.
There is no more PAC caging.
We're doing this because there are performance issues with PAC caging
that we haven't resolved yet.
* assembler/CPU.h:
(JSC::isARM64E): Deleted.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted.
(JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted.
(JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted.
* b3/B3LowerToAir.cpp:
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::admitsStack):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
(JSC::B3::StackmapSpecial::isArgValidForRep):
* b3/B3Validate.cpp:
* b3/B3ValueRep.cpp:
(JSC::B3::ValueRep::addUsedRegistersTo const):
(JSC::B3::ValueRep::dump const):
(WTF::printInternal):
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::ValueRep):
(JSC::B3::ValueRep::isReg const):
* dfg/DFGOperations.cpp:
(JSC::DFG::newTypedArrayWithSize):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
(JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
(JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
(JSC::FTL::DFG::LowerDFGToB3::caged):
(JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
(JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted.
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::genericAddPointer):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageConditionally):
* jit/IntrinsicEmitter.cpp:
(JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitDirectArgumentsGetByVal):
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::clearCallLinkInfo):
* jit/RegisterSet.h:
* llint/LowLevelInterpreter64.asm:
* runtime/ArrayBuffer.cpp:
(JSC::SharedArrayBufferContents::SharedArrayBufferContents):
(JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
(JSC::ArrayBufferContents::ArrayBufferContents):
(JSC::ArrayBufferContents::destroy):
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBufferContents::makeShared):
(JSC::ArrayBufferContents::copyTo):
* runtime/ArrayBuffer.h:
(JSC::SharedArrayBufferContents::data const):
(JSC::ArrayBufferContents::data const):
(JSC::ArrayBuffer::data):
(JSC::ArrayBuffer::data const):
(JSC::ArrayBuffer::byteLength const):
* runtime/ArrayBufferView.cpp:
(JSC::ArrayBufferView::ArrayBufferView):
* runtime/ArrayBufferView.h:
(JSC::ArrayBufferView::baseAddress const):
(JSC::ArrayBufferView::setRangeImpl):
(JSC::ArrayBufferView::getRangeImpl):
(JSC::ArrayBufferView::byteLength const): Deleted.
* runtime/CachedTypes.cpp:
(JSC::CachedScopedArgumentsTable::encode):
(JSC::CachedScopedArgumentsTable::decode const):
* runtime/CagedBarrierPtr.h:
(JSC::CagedBarrierPtr::CagedBarrierPtr):
(JSC::CagedBarrierPtr::set):
(JSC::CagedBarrierPtr::get const):
(JSC::CagedBarrierPtr::getMayBeNull const):
(JSC::CagedBarrierPtr::operator== const):
(JSC::CagedBarrierPtr::operator!= const):
(JSC::CagedBarrierPtr::operator bool const):
(JSC::CagedBarrierPtr::setWithoutBarrier):
(JSC::CagedBarrierPtr::operator* const):
(JSC::CagedBarrierPtr::operator-> const):
(JSC::CagedBarrierPtr::operator[] const):
(JSC::CagedBarrierPtr::getUnsafe const): Deleted.
(JSC::CagedBarrierPtr::at const): Deleted.
* runtime/DataView.cpp:
(JSC::DataView::DataView):
* runtime/DataView.h:
(JSC::DataView::get):
(JSC::DataView::set):
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::visitChildren):
(JSC::DirectArguments::overrideThings):
(JSC::DirectArguments::unmapArgument):
* runtime/DirectArguments.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::visitChildren):
(JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
(JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
(JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
* runtime/GenericTypedArrayView.h:
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
(JSC::JSArrayBufferView::JSArrayBufferView):
(JSC::JSArrayBufferView::finalize):
(JSC::JSArrayBufferView::slowDownAndWasteMemory):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::ConstructionContext::vector const):
(JSC::JSArrayBufferView::isNeutered):
(JSC::JSArrayBufferView::vector const):
(JSC::JSArrayBufferView::hasVector const): Deleted.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
(JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
* runtime/Options.h:
* runtime/ScopedArgumentsTable.cpp:
(JSC::ScopedArgumentsTable::clone):
(JSC::ScopedArgumentsTable::setLength):
* runtime/ScopedArgumentsTable.h:
* runtime/SymbolTable.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::complete):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::cachedMemory const):
(JSC::Wasm::Instance::updateCachedMemory):
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::~Memory):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::Memory::dump const):
* wasm/WasmMemory.h:
(JSC::Wasm::Memory::memory const):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2019-06-10 Basuke Suzuki <Basuke.Suzuki@sony.com>
[WinCairo] Remove build warning from RemoteInspector.
https://bugs.webkit.org/show_bug.cgi?id=198724
Reviewed by Joseph Pecoraro.
In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation.
This method is to be overwritten by sub classes so that parameter name is important
so they are commented out rather than just removing from the definition.
* inspector/remote/RemoteInspector.h:
2019-06-10 Sam Weinig <weinig@apple.com>
Remove Dashboard support
https://bugs.webkit.org/show_bug.cgi?id=198615
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2019-06-10 Devin Rousso <drousso@apple.com>
Web Automation: add notifications for when remote automation is enabled/disabled
https://bugs.webkit.org/show_bug.cgi?id=198703
<rdar://problem/50588975>
Reviewed by Timothy Hatcher.
* inspector/remote/RemoteInspectorConstants.h:
2019-06-10 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for non-DFG configurations, part 2
https://bugs.webkit.org/show_bug.cgi?id=198023
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
2019-06-10 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for non-DFG configurations
https://bugs.webkit.org/show_bug.cgi?id=198023
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
2019-06-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode
https://bugs.webkit.org/show_bug.cgi?id=198023
Reviewed by Saam Barati.
While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications.
When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable.
And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge
UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually
be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have
navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in
web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will
hit the uppermost of memory footprint. But until that, we increase our memory footprint.
However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any
time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain.
One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused.
But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression.
But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never
reuse these CodeCache since we do not have the navigation.
This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC
cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a
heuristic. In a super pathological case, it could increase memory footprint. Consider the following example.
UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1)
^
CodeBlock(E1)
We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and
we will create duplicate UnlinkedCodeBlock and instructions stream for D1.
UnlinkedCodeBlock(D1)
^
CodeBlock(E1)
UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2)
But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do
not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB).
While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64,
while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation.
Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising.
If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode
cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption
will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK.
This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable ->
UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed
While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable ->
UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held
by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old.
If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first
heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying
the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a
good starting point.
Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times.
It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0).
If we want to get more memory reduction for the sake of performance, we could decrease this age limit.
Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves
memory footprint of our target application from about 6.5 MB to about 5.9 MB.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
* bytecode/CodeBlock.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedCodeBlock::visitChildren):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::age const):
(JSC::UnlinkedCodeBlock::resetAge):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::visitChildren):
(JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
(JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
(JSC::UnlinkedFunctionExecutable::finalizeUnconditionally):
* bytecode/UnlinkedFunctionExecutable.h:
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
* runtime/CachedTypes.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* runtime/CodeSpecializationKind.h:
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::isInMiniMode): Deleted.
* runtime/VM.h:
(JSC::VM::isInMiniMode):
(JSC::VM::useUnlinkedCodeBlockJettisoning):
2019-06-10 Timothy Hatcher <timothy@apple.com>
Integrate dark mode support for iOS.
https://bugs.webkit.org/show_bug.cgi?id=198687
rdar://problem/51545643
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2019-06-10 Adrian Perez de Castro <aperez@igalia.com>
[JSC] Linker fails when unified sources are not in use
https://bugs.webkit.org/show_bug.cgi?id=198722
Reviewed by Keith Miller.
Added missing inclusions of headers in several files which make use of inline functions.
* b3/B3AtomicValue.cpp:
* b3/B3BlockInsertionSet.cpp:
* b3/B3FenceValue.cpp:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3PureCSE.cpp:
* b3/B3StackmapValue.cpp:
* b3/B3SwitchValue.cpp:
* b3/B3UseCounts.cpp:
* b3/B3VariableValue.cpp:
* b3/B3WasmAddressValue.cpp:
* b3/B3WasmBoundsCheckValue.cpp:
* ftl/FTLCompile.cpp:
* wasm/WasmSectionParser.cpp:
* wasm/WasmTable.cpp:
* wasm/WasmValidate.cpp:
2019-06-10 Keith Miller <keith_miller@apple.com>
Make new Symbol/Promise API public
https://bugs.webkit.org/show_bug.cgi?id=198709
Reviewed by Saam Barati.
We also need to #ifdef some tests when building for older
platforms because the signatures for some methods are outdated on
those platforms.
* API/JSObjectRef.h:
* API/JSObjectRefPrivate.h:
* API/JSValue.h:
* API/JSValuePrivate.h:
* API/JSValueRef.h:
* API/tests/testapi.mm:
(testObjectiveCAPIMain):
2019-06-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r246150, r246160, and r246166.
https://bugs.webkit.org/show_bug.cgi?id=198698
Regresses page loading time on iOS 13 (Requested by keith_m__
on #webkit).
Reverted changesets:
"Reenable Gigacage on ARM64."
https://bugs.webkit.org/show_bug.cgi?id=198453
https://trac.webkit.org/changeset/246150
"Unrevied build fix for FTL without Gigacage."
https://trac.webkit.org/changeset/246160
"Fix typo in cageWithoutUntagging"
https://bugs.webkit.org/show_bug.cgi?id=198617
https://trac.webkit.org/changeset/246166
2019-06-09 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use mergePrediction in ValuePow prediction propagation
https://bugs.webkit.org/show_bug.cgi?id=198648
Reviewed by Saam Barati.
We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant)
must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard
previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead.
* dfg/DFGPredictionPropagationPhase.cpp:
2019-06-07 Tadeu Zagallo <tzagallo@apple.com>
AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset
https://bugs.webkit.org/show_bug.cgi?id=198581
<rdar://problem/51099753>
Reviewed by Saam Barati.
For GetGetterSetterByOffset, when the abstract interpreter fails to read the property
from the object, it gets the GetterSetter structure from the CodeBlock's global object.
However, that's not correct, since the global object for the base object might differ
from the CodeBlock's. Instead, we try to get the global object from the base, when it's
a constant object. Otherwise, we can't infer the value and only set the type.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019-06-06 Devin Rousso <drousso@apple.com>
Web Inspector: create CommandLineAPIHost lazily like the other agents
https://bugs.webkit.org/show_bug.cgi?id=196047
<rdar://problem/49087835>
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptManager.h:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::connect): Added.
2019-06-06 Keith Miller <keith_miller@apple.com>
Fix typo in cageWithoutUntagging
https://bugs.webkit.org/show_bug.cgi?id=198617
Reviewed by Saam Barati.
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageWithoutUntagging):
(JSC::AssemblyHelpers::cageConditionally):
(JSC::AssemblyHelpers::cageWithoutUntaging): Deleted.
2019-06-06 Alexey Shvayka <shvaikalesh@gmail.com>
JSON.parse throws incorrect exception when called w/o arguments
https://bugs.webkit.org/show_bug.cgi?id=198574
Reviewed by Yusuke Suzuki.
Always coerce first argument to string and attempt to parse it.
(steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse)
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncParse): Remove argumentCount check.
2019-06-06 Keith Miller <keith_miller@apple.com>
Unrevied build fix for FTL without Gigacage.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged):
2019-06-06 Michael Catanzaro <mcatanzaro@igalia.com>
aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’}
https://bugs.webkit.org/show_bug.cgi?id=198014
Reviewed by Yusuke Suzuki.
When building for aarch64, there is a huge warning spam here. It's impossible to see any
other warnings. This has been ongoing for so long I've begun to suspect that nobody works
on this architecture.
Anyway, the problem is because we need eight bits to store all possible RegisterID values,
but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this
struct is still happy, so I presume the change is OK.
* assembler/ARM64Assembler.h:
2019-06-06 Keith Miller <keith_miller@apple.com>
Reenable Gigacage on ARM64.
https://bugs.webkit.org/show_bug.cgi?id=198453
Reviewed by Michael Saboff.
This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
old Gigacage however, arm64e uses both Gigacaging and PAC. In
order to ensure the PAC bits are not stripped in the caging
process we use the bit field insert instruction to take the low
bits from caging and the high bits from the PAC authentication.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::bitFieldInsert64):
* assembler/MacroAssemblerARM64E.h:
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
(JSC::run):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
(JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::caged):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageWithoutUntaging):
(JSC::AssemblyHelpers::cageConditionally):
(JSC::AssemblyHelpers::cage): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayGetByVal):
(JSC::JIT::emitFloatTypedArrayGetByVal):
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/arm64.rb:
* offlineasm/instructions.rb:
* offlineasm/registers.rb:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2019-06-06 Michael Saboff <msaboff@apple.com>
[ARM64E]: Add disassembler support for authenticated instructions
https://bugs.webkit.org/show_bug.cgi?id=198562
Reviewed by Keith Miller.
Added support for all the instructions supported in ARM64EAssembler.h.
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
(JSC::ARM64Disassembler::A64DOpcodeHint::format):
(JSC::ARM64Disassembler::A64DOpcodeHint::opName):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit):
(JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm):
(JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted.
2019-06-05 Justin Michaud <justin_michaud@apple.com>
[WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only).
https://bugs.webkit.org/show_bug.cgi?id=198398
Reviewed by Saam Barati.
Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec).
Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to
support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because
we need to write barrier it (so it should not restrict how we implement threads). This patch does, however,
restrict the implementation of function references to require every Ref.func to have an associated wrapper. This
can be done statically, so this too should not restrict our threads implementation.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addTableGet):
(JSC::Wasm::AirIRGenerator::addTableSet):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addLocal):
(JSC::Wasm::B3IRGenerator::addTableGet):
(JSC::Wasm::B3IRGenerator::addTableSet):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmFormat.h:
(JSC::Wasm::TableInformation::TableInformation):
(JSC::Wasm::TableInformation::type const):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseTableHelper):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::Table):
(JSC::Wasm::Table::tryCreate):
(JSC::Wasm::Table::grow):
(JSC::Wasm::Table::clear):
(JSC::Wasm::Table::set):
(JSC::Wasm::Table::get):
(JSC::Wasm::Table::visitChildren):
(JSC::Wasm::FuncRefTable::FuncRefTable):
(JSC::Wasm::FuncRefTable::setFunction):
(JSC::Wasm::Table::~Table): Deleted.
(JSC::Wasm::Table::clearFunction): Deleted.
(JSC::Wasm::Table::setFunction): Deleted.
* wasm/WasmTable.h:
(JSC::Wasm::Table::length const):
(JSC::Wasm::Table::type const):
(JSC::Wasm::Table::setOwner):
(JSC::Wasm::FuncRefTable::offsetOfFunctions):
(JSC::Wasm::FuncRefTable::offsetOfInstances):
(JSC::Wasm::Table::offsetOfFunctions): Deleted.
(JSC::Wasm::Table::offsetOfInstances): Deleted.
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addTableGet):
(JSC::Wasm::Validate::addTableSet):
(JSC::Wasm::Validate::addCallIndirect):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::finishCreation):
(JSC::JSWebAssemblyTable::visitChildren):
(JSC::JSWebAssemblyTable::grow):
(JSC::JSWebAssemblyTable::get):
(JSC::JSWebAssemblyTable::set):
(JSC::JSWebAssemblyTable::clear):
(JSC::JSWebAssemblyTable::getFunction): Deleted.
(JSC::JSWebAssemblyTable::clearFunction): Deleted.
(JSC::JSWebAssemblyTable::setFunction): Deleted.
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::webAssemblyTableProtoFuncGet):
(JSC::webAssemblyTableProtoFuncSet):
* wasm/wasm.json:
2019-06-05 Justin Michaud <justin_michaud@apple.com>
WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0
https://bugs.webkit.org/show_bug.cgi?id=198106
Reviewed by Saam Barati.
Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::moveDoubleConditionally32):
2019-06-05 Alex Christensen <achristensen@webkit.org>
Progress towards resurrecting Mac CMake build
https://bugs.webkit.org/show_bug.cgi?id=197132
Reviewed by Don Olmstead.
* API/JSScript.mm:
(-[JSScript readCache]):
(-[JSScript sourceCode]):
(-[JSScript jsSourceCode]):
(-[JSScript writeCache:]):
* CMakeLists.txt:
== Rolled over to ChangeLog-2019-06-05 ==