[webkit-changes] [WebKit/WebKit] 5a241c: Destructuring exception shouldn't crash
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 5a241c1e2822e6ad1b32aca9db53babb28e0b375 https://github.com/WebKit/WebKit/commit/5a241c1e2822e6ad1b32aca9db53babb28e0b375 Author: Keith Miller Date: 2024-02-07 (Wed, 07 Feb 2024) Changed paths: A JSTests/stress/destructuring-class-in-constructor-exception.js M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h M Source/JavaScriptCore/parser/ASTBuilder.h M Source/JavaScriptCore/parser/Parser.cpp M Source/JavaScriptCore/parser/ParserTokens.h M Source/JavaScriptCore/parser/SyntaxChecker.h Log Message: --- Destructuring exception shouldn't crash https://bugs.webkit.org/show_bug.cgi?id=268849 rdar://121869296 Reviewed by Yusuke Suzuki. We recently changed how we saved expression info for exceptions, which saved a bunch of memory. The new system exposed some places where we were not setting JSTextPositions properly. This patch fixes that and adds some asserts that the expression info is initialized. We also now return early rather than emit bad expression info if not all parts are initialized in production. This means users will see the wrong expression in their stack trace but we won't crash. * JSTests/stress/destructuring-class-in-constructor-exception.js: Added. (try.C0): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitExpressionInfo): * Source/JavaScriptCore/parser/ASTBuilder.h: (JSC::ASTBuilder::finishObjectPattern): (JSC::ASTBuilder::setExceptionLocation): * Source/JavaScriptCore/parser/Parser.cpp: (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseForStatement): * Source/JavaScriptCore/parser/ParserTokens.h: (JSC::JSTextPosition::operator bool const): * Source/JavaScriptCore/parser/SyntaxChecker.h: (JSC::SyntaxChecker::operatorStackPop): Canonical link: https://commits.webkit.org/274213@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] fb4741: [IPInt] Add stack overflow checks
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: fb47415c1ad4bfc008367fffe637384f93757531 https://github.com/WebKit/WebKit/commit/fb47415c1ad4bfc008367fffe637384f93757531 Author: Keith Miller Date: 2024-02-20 (Tue, 20 Feb 2024) Changed paths: R JSTests/wasm/ipint-tests/ipint-stress-i32.js R JSTests/wasm/ipint-tests/ipint-stress-i32.wasm R JSTests/wasm/ipint-tests/ipint-stress-lol.js R JSTests/wasm/ipint-tests/ipint-test-stress.js M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmCallee.h M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h M Source/JavaScriptCore/wasm/WasmFunctionParser.h M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp Log Message: --- [IPInt] Add stack overflow checks https://bugs.webkit.org/show_bug.cgi?id=269788 Reviewed by Justin Michaud. Right now IPInt doesn't do stack overflow checks. This patch adds them by tracking the stack height after decoding each opcode. This is done by calling `changeStackSize(delta)`. We will validate after each opcode that the stack height matches what the Parser sees on debug builds. Also, this patch removes some IPInt stress tests that take a long time to run. * JSTests/wasm/ipint-tests/ipint-stress-i32.js: Removed. * JSTests/wasm/ipint-tests/ipint-stress-i32.wasm: Removed. * JSTests/wasm/ipint-tests/ipint-stress-lol.js: Removed. * JSTests/wasm/ipint-tests/ipint-test-stress.js: Removed. * Source/JavaScriptCore/llint/InPlaceInterpreter.asm: * Source/JavaScriptCore/wasm/WasmCallee.cpp: (JSC::Wasm::IPIntCallee::IPIntCallee): * Source/JavaScriptCore/wasm/WasmCallee.h: * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h: * Source/JavaScriptCore/wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::getStackHeightInValues const): (JSC::Wasm::FunctionParser::getControlEntryStackHeightInValues const): * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntControlType::IPIntControlType): (JSC::Wasm::IPIntControlType::stackSize const): (JSC::Wasm::IPIntGenerator::didParseOpcode): (JSC::Wasm::IPIntGenerator::changeStackSize): (JSC::Wasm::IPIntGenerator::addDrop): (JSC::Wasm::IPIntGenerator::addConstant): (JSC::Wasm::IPIntGenerator::addExtractLane): (JSC::Wasm::IPIntGenerator::addRefIsNull): (JSC::Wasm::IPIntGenerator::addRefFunc): (JSC::Wasm::IPIntGenerator::addRefAsNonNull): (JSC::Wasm::IPIntGenerator::addRefEq): (JSC::Wasm::IPIntGenerator::addTableGet): (JSC::Wasm::IPIntGenerator::addTableSet): (JSC::Wasm::IPIntGenerator::addTableInit): (JSC::Wasm::IPIntGenerator::addElemDrop): (JSC::Wasm::IPIntGenerator::addTableSize): (JSC::Wasm::IPIntGenerator::addTableGrow): (JSC::Wasm::IPIntGenerator::addTableFill): (JSC::Wasm::IPIntGenerator::addTableCopy): (JSC::Wasm::IPIntGenerator::addArguments): (JSC::Wasm::IPIntGenerator::addLocal): (JSC::Wasm::IPIntGenerator::getLocal): (JSC::Wasm::IPIntGenerator::setLocal): (JSC::Wasm::IPIntGenerator::getGlobal): (JSC::Wasm::IPIntGenerator::setGlobal): (JSC::Wasm::IPIntGenerator::load): (JSC::Wasm::IPIntGenerator::store): (JSC::Wasm::IPIntGenerator::addGrowMemory): (JSC::Wasm::IPIntGenerator::addCurrentMemory): (JSC::Wasm::IPIntGenerator::addMemoryFill): (JSC::Wasm::IPIntGenerator::addMemoryCopy): (JSC::Wasm::IPIntGenerator::addMemoryInit): (JSC::Wasm::IPIntGenerator::addDataDrop): (JSC::Wasm::IPIntGenerator::atomicLoad): (JSC::Wasm::IPIntGenerator::atomicStore): (JSC::Wasm::IPIntGenerator::atomicBinaryRMW): (JSC::Wasm::IPIntGenerator::atomicCompareExchange): (JSC::Wasm::IPIntGenerator::atomicWait): (JSC::Wasm::IPIntGenerator::atomicNotify): (JSC::Wasm::IPIntGenerator::atomicFence): (JSC::Wasm::IPIntGenerator::addArrayFill): (JSC::Wasm::IPIntGenerator::addArrayCopy): (JSC::Wasm::IPIntGenerator::addArrayInitElem): (JSC::Wasm::IPIntGenerator::addArrayInitData): (JSC::Wasm::IPIntGenerator::addI32Add): (JSC::Wasm::IPIntGenerator::addI64Add): (JSC::Wasm::IPIntGenerator::addI32Sub): (JSC::Wasm::IPIntGenerator::addI64Sub): (JSC::Wasm::IPIntGenerator::addI32Mul): (JSC::Wasm::IPIntGenerator::addI64Mul): (JSC::Wasm::IPIntGenerator::addI32DivS): (JSC::Wasm::IPIntGenerator::addI32DivU): (JSC::Wasm::IPIntGenerator::addI64DivS): (JSC::Wasm::IPIntGenerator::addI64DivU): (JSC::Wasm::IPIntGenerator::addI32RemS): (JSC::Wasm::IPIntGenerator::addI32RemU): (JSC::Wasm::IPIntGenerator::addI64RemS): (JSC::Wasm::IPIntGenerator::addI64RemU): (JSC::Wasm::IPIntGenerator::addI32And): (JSC::Wasm::IPIntGenerator::addI64And): (JSC::Wasm::IPIntGenerator::addI32Xor): (JSC::Wasm::IPIntGenerator::addI64Xor): (JSC::Wasm::IPIntGenerator::addI32Or): (JSC::Wasm::IPIntGenerator::addI64Or): (JSC::Wasm::IPIntGenerator::addI32Shl): (JSC::Wasm::IPIntGenerator::addI32ShrU): (JSC::Wasm::IPIntGenerator::addI32ShrS): (JSC::Wasm::IPIntGenerator::addI64Shl): (JSC::Wasm::IPIntGenerator::addI64ShrU): (JSC::Wasm::IPIntGenerator::addI64ShrS): (JSC:
[webkit-changes] [WebKit/WebKit] 3e74b0: B3::ReduceStrength is overly conservative at apply...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 3e74b00e473fe2a37662b206e4615c97d85a456f https://github.com/WebKit/WebKit/commit/3e74b00e473fe2a37662b206e4615c97d85a456f Author: Keith Miller Date: 2024-03-06 (Wed, 06 Mar 2024) Changed paths: M Source/JavaScriptCore/b3/B3ReduceStrength.cpp Log Message: --- B3::ReduceStrength is overly conservative at applying specializeSelect https://bugs.webkit.org/show_bug.cgi?id=270577 rdar://124146878 Reviewed by Justin Michaud. Right now it only applies if both outputs from a select are constant. The comment and testing indicates this is profitable as long as one of the two outputs is a constant. This looks like a 1.7% speedup on JS3. * Source/JavaScriptCore/b3/B3ReduceStrength.cpp: Canonical link: https://commits.webkit.org/275765@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] acfa63: Add disassembleBase64 function to jsc cli
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: acfa63bc90bc133dab16f9512a77fe159adcb5b7 https://github.com/WebKit/WebKit/commit/acfa63bc90bc133dab16f9512a77fe159adcb5b7 Author: Keith Miller Date: 2024-03-08 (Fri, 08 Mar 2024) Changed paths: M Source/JavaScriptCore/disassembler/Disassembler.h M Source/JavaScriptCore/jsc.cpp Log Message: --- Add disassembleBase64 function to jsc cli https://bugs.webkit.org/show_bug.cgi?id=270707 rdar://124288714 Reviewed by Justin Michaud. Sometimes we get crash reports that have some assembly around the crashing JIT pc. This code is encoded in base64 but unfortunately `btoa` gives the code back with the wrong endianness, I think anyway. Rather than figure out how to flip the endianness I just decided to roll everything into one function. * Source/JavaScriptCore/disassembler/Disassembler.h: * Source/JavaScriptCore/jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): * Source/WTF/wtf/text/StringImpl.h: (WTF::StringImpl::data const): Canonical link: https://commits.webkit.org/275853@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 2a042f: [JSC] JSCell::toX should use jsDynamicCast/jsSecur...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 2a042fede0e705bae4b8ce039b18442696ebb5ce https://github.com/WebKit/WebKit/commit/2a042fede0e705bae4b8ce039b18442696ebb5ce Author: Keith Miller Date: 2024-03-11 (Mon, 11 Mar 2024) Changed paths: M Source/JavaScriptCore/runtime/JSCell.cpp Log Message: --- [JSC] JSCell::toX should use jsDynamicCast/jsSecureCast https://bugs.webkit.org/show_bug.cgi?id=270797 rdar://124119022 Reviewed by Mark Lam. General code quality improvement. We also might as well add a release assert that the final case is correct as it doesn't seem to be a perf regression. * Source/JavaScriptCore/runtime/JSCell.cpp: (JSC::JSCell::toPrimitive const): (JSC::JSCell::toNumber const): (JSC::JSCell::toObjectSlow const): Canonical link: https://commits.webkit.org/275948@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 29536a: Build scripts should default to the Internal works...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 29536a50b549dd94eaa0f0f6c6a60e364a62dee5 https://github.com/WebKit/WebKit/commit/29536a50b549dd94eaa0f0f6c6a60e364a62dee5 Author: Keith Miller Date: 2024-03-19 (Tue, 19 Mar 2024) Changed paths: M Tools/Scripts/webkitdirs.pm M Tools/Scripts/webkitperl/BuildSubproject.pm Log Message: --- Build scripts should default to the Internal workspace using the internal SDK https://bugs.webkit.org/show_bug.cgi?id=271245 rdar://125015308 Reviewed by Elliott Williams. Right now in order to get WebKitAdditions when using these scripts you have to already have started a build from Internal. This is annoying for clean builds or when WebKitBuild has a stale WebKitAdditions. This patch changes the build scripts to default to the Internal workspace when building for a .internal SDK and the regular workspace when building for a public SDK. If there's already a configured workspace then we just use that. * Tools/Scripts/webkitdirs.pm: (determineConfiguredXcodeWorkspaceOrDefault): (configuredXcodeWorkspace): (XcodeOptions): (determineConfiguredXcodeWorkspace): Deleted. * Tools/Scripts/webkitperl/BuildSubproject.pm: (buildUpToProject): Canonical link: https://commits.webkit.org/276366@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 66f743: New exception handler adoption with fallback
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 66f743ca6ca6bdbf5241994991b09c8aba0c1c06 https://github.com/WebKit/WebKit/commit/66f743ca6ca6bdbf5241994991b09c8aba0c1c06 Author: Keith Miller Date: 2024-03-22 (Fri, 22 Mar 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/runtime/InitializeThreading.cpp M Source/JavaScriptCore/runtime/MachineContext.h M Source/JavaScriptCore/runtime/VMTraps.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h M Source/WTF/WTF.xcodeproj/project.pbxproj M Source/WTF/wtf/PlatformJSCOnly.cmake M Source/WTF/wtf/PlatformMac.cmake M Source/WTF/wtf/PlatformRegisters.cpp M Source/WTF/wtf/PlatformRegisters.h M Source/WTF/wtf/spi/darwin/SandboxSPI.h M Source/WTF/wtf/threads/Signals.cpp M Source/WTF/wtf/threads/Signals.h M Source/WTF/wtf/win/SignalsWin.cpp M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in M Source/WebKit/WebProcess/com.apple.WebProcess.sb.in M Tools/TestWebKitAPI/Tests/WTF/Signals.cpp Log Message: --- New exception handler adoption with fallback https://bugs.webkit.org/show_bug.cgi?id=271489 rdar://119256062 Reviewed by Per Arne Vollan. Patch by Brandon Kayes and Keith Miller. This adopts the new hardened mach exception mechanism which was introduced in darwin recently. See the radar for more details. This attempt to land this patch should work with stale sandbox profiles, which was causing problems with the previous iteration. * Source/JavaScriptCore/jsc.cpp: (main): (CommandLine::parseArguments): * Source/JavaScriptCore/runtime/InitializeThreading.cpp: (JSC::initialize): * Source/JavaScriptCore/runtime/MachineContext.h: (JSC::MachineContext::setInstructionPointer): * Source/JavaScriptCore/runtime/VMTraps.cpp: * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::MachExceptionSigningKey::MachExceptionSigningKey): (JSC::Wasm::trapHandler): (JSC::Wasm::activateSignalingMemory): (): Deleted. * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h: * Source/WTF/WTF.xcodeproj/project.pbxproj: * Source/WTF/wtf/PlatformJSCOnly.cmake: * Source/WTF/wtf/PlatformMac.cmake: * Source/WTF/wtf/PlatformRegisters.cpp: (WTF::threadStatePCInternal): * Source/WTF/wtf/PlatformRegisters.h: * Source/WTF/wtf/spi/darwin/SandboxSPI.h: * Source/WTF/wtf/threads/Signals.cpp: (WTF::initMachExceptionHandlerThread): (WTF::setExceptionPorts): (WTF::activateSignalHandlersFor): (WTF::finalizeSignalHandlers): (WTF::toMachMask): Deleted. * Source/WTF/wtf/threads/Signals.h: (WTF::toMachMask): (WTF::initializeSignalHandling): (WTF::disableSignalHandling): * Source/WTF/wtf/win/SignalsWin.cpp: (WTF::finalizeSignalHandlers): * Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in: * Source/WebKit/WebProcess/com.apple.WebProcess.sb.in: * Tools/TestWebKitAPI/Tests/WTF/Signals.cpp: (TEST): Canonical link: https://commits.webkit.org/276579@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 851d99: Refactor mach exception sandboxing rules for mac
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 851d99c108a97eaddb3789b0bfb99f32870b5b13 https://github.com/WebKit/WebKit/commit/851d99c108a97eaddb3789b0bfb99f32870b5b13 Author: Keith Miller Date: 2024-03-23 (Sat, 23 Mar 2024) Changed paths: M Source/WebKit/WebProcess/com.apple.WebProcess.sb.in Log Message: --- Refactor mach exception sandboxing rules for mac https://bugs.webkit.org/show_bug.cgi?id=271530 rdar://125301161 Reviewed by Per Arne Vollan. This fixes a bug where we weren't allowing thread_set_exception_ports after webcontent-process-launched (after the first content was loaded). Also, I think it makes the logic flow a bit clearer. * Source/WebKit/WebProcess/com.apple.WebProcess.sb.in: Canonical link: https://commits.webkit.org/276605@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 73dc60: [JSC] run-jsc-stress-tests should set argv for cra...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 73dc6018058341397934f03d01f8cfe143d1052e https://github.com/WebKit/WebKit/commit/73dc6018058341397934f03d01f8cfe143d1052e Author: Keith Miller Date: 2024-04-04 (Thu, 04 Apr 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Tools/Scripts/run-jsc-stress-tests Log Message: --- [JSC] run-jsc-stress-tests should set argv for crash reporter. https://bugs.webkit.org/show_bug.cgi?id=272155 rdar://125907089 Reviewed by Mark Lam and Yusuke Suzuki. Right now when we get internal crash reports from our testers it can be hard to figure out which test crashed. Set Application Specific Information when the JSCTEST_CrashReportArgV environment variable is set. Use an environment variable as there could be privacy concerns if we set ASI every time we invoke `jsc`. * Source/JavaScriptCore/jsc.cpp: (main): * Tools/Scripts/run-jsc-stress-tests: Canonical link: https://commits.webkit.org/277067@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] b3ecee: Clean up Signals and remove hardened fallback
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b3eceeb22f58375c3ae39ccdc376335e417881fe https://github.com/WebKit/WebKit/commit/b3eceeb22f58375c3ae39ccdc376335e417881fe Author: Keith Miller Date: 2024-04-05 (Fri, 05 Apr 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/runtime/InitializeThreading.cpp M Source/JavaScriptCore/runtime/JSCConfig.cpp M Source/JavaScriptCore/runtime/JSCConfig.h M Source/JavaScriptCore/runtime/VM.cpp M Source/JavaScriptCore/runtime/VMEntryScope.cpp M Source/JavaScriptCore/runtime/VMTraps.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h M Source/WTF/wtf/PlatformRegisters.cpp M Source/WTF/wtf/Threading.cpp M Source/WTF/wtf/WTFConfig.cpp M Source/WTF/wtf/WTFConfig.h M Source/WTF/wtf/threads/Signals.cpp M Source/WTF/wtf/threads/Signals.h M Source/WTF/wtf/win/SignalsWin.cpp M Source/WebKit/GPUProcess/EntryPoint/Cocoa/XPCService/GPUServiceEntryPoint.mm M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in M Tools/TestWebKitAPI/Tests/WTF/Signals.cpp Log Message: --- Clean up Signals and remove hardened fallback https://bugs.webkit.org/show_bug.cgi?id=271766 rdar://125256111 Reviewed by Justin Michaud. This change does a couple of things: 1) Refactor the signal handler API after https://commits.webkit.org/276579@main which had mach exception users pass the mask of exceptions they would ever want to handle at initialization time (before they register their handler). Instead the new signal handler API registers our handlers with the kernel at finalization time. At which point we have a list of every exception handler added. 2) Remove the finalizeSignalHandlers function and finalize signal handlers when WTF::Config finalizes. 3) Remove disableSignalHandling function as it never really worked (signals could still get registered before we called disable) and we mostly rely on the sandbox to block signals in lockdown mode. 3) Rename SignalHandlers::InitState entries to better reflect the new design and use it for all configurations not just mach ports. 4) Remove the fallback we added to https://commits.webkit.org/276579@main as a stopgap for internal folks running on old sandboxes. 5) Remove `isX86BinaryRunningOnARM()` check since that didn't seem to work anyway. We'll probably have to remove signal handling under Rosetta as I couldn't get it to work. 6) Save the secret key for our hardened handler in Signals.cpp before finalization and only let API users see it via presignReturnPCForHandler so they can't accidentally save it somewhere an attacker could see later. We also carefully zero it at finalization time after passing it to the kernel via `task_register_hardened_exception_handler`. 7) Move disabledFreezingForTesting to WTF::Config since that's the config that actually does the freezing not JSC::Config. This allows WTF::Config to control finalizing signal handlers. 8) Remove some cases from com.apple.WebKit.WebContent.sb.in to simplify the profile slightly. We don't need to guard the `(require-not (webcontent-process-launched))` check on `ENABLE(BLOCK_SET_EXCEPTION_PORTS)` because we have `webcontent-process-launched` anywhere we `HAVE(HARDENED_MACH_EXCEPTIONS)` anyway. * Source/JavaScriptCore/jsc.cpp: (main): (CommandLine::parseArguments): * Source/JavaScriptCore/runtime/InitializeThreading.cpp: (JSC::initialize): * Source/JavaScriptCore/runtime/JSCConfig.cpp: (JSC::Config::disableFreezingForTesting): Deleted. * Source/JavaScriptCore/runtime/JSCConfig.h: (JSC::Config::disableFreezingForTesting): (JSC::Config::finalize): (JSC::Config::permanentlyFreeze): Deleted. * Source/JavaScriptCore/runtime/VM.cpp: (JSC::VM::VM): * Source/JavaScriptCore/runtime/VMEntryScope.cpp: (JSC::VMEntryScope::setUpSlow): * Source/JavaScriptCore/runtime/VMTraps.cpp: * Source/JavaScriptCore/tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES): * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::activateSignalingMemory): (JSC::Wasm::prepareSignalingMemory): (JSC::Wasm::MachExceptionSigningKey::MachExceptionSigningKey): Deleted. * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h: * Source/WTF/wtf/PlatformRegisters.cpp: (WTF::threadStatePCInternal): * Source/WTF/wtf/Threading.cpp: (WTF::initialize): * Source/WTF/wtf/WTFConfig.cpp: (WTF::Config::initialize): (WTF::Config::finalize): (WTF::Config::permanentlyFreeze): (WTF::Config::disableFreezingForTesting): * Source/WTF/wtf/WTFConfig.h: * Source/WTF/wtf/threads/Signals.cpp: (WTF::SignalHandlers::add): (WTF::SignalHandlers::presignReturnPCForHandler): (WTF::initMachExceptionHandlerThread): (WTF::toMachMask):
[webkit-changes] [WebKit/WebKit] b97e64: Don't initialize mach exceptions if we didn't regi...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b97e643c5d3420737a797a79a277add465ea5fa1 https://github.com/WebKit/WebKit/commit/b97e643c5d3420737a797a79a277add465ea5fa1 Author: Keith Miller Date: 2024-04-05 (Fri, 05 Apr 2024) Changed paths: M Source/WTF/wtf/threads/Signals.cpp Log Message: --- Don't initialize mach exceptions if we didn't register any. https://bugs.webkit.org/show_bug.cgi?id=272261 rdar://126000755 Reviewed by Justin Michaud. This also fixes GPU process crashing on launch because the sandbox doesn't allow `task_register_hardened_exception_handler`. * Source/WTF/wtf/threads/Signals.cpp: (WTF::initMachExceptionHandlerThread): Canonical link: https://commits.webkit.org/277143@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 8bc5a4: ASCIILiteral could be a wrapper around std::span
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 8bc5a4faf17f080969fd19205c89a90b0a82da47 https://github.com/WebKit/WebKit/commit/8bc5a4faf17f080969fd19205c89a90b0a82da47 Author: Keith Miller Date: 2024-04-07 (Sun, 07 Apr 2024) Changed paths: M Source/WTF/wtf/HashTraits.h M Source/WTF/wtf/text/ASCIILiteral.cpp M Source/WTF/wtf/text/ASCIILiteral.h Log Message: --- ASCIILiteral could be a wrapper around std::span https://bugs.webkit.org/show_bug.cgi?id=272173 rdar://125920640 Reviewed by Chris Dumez. Right now ASCIILiteral just points to a `const char*` but now that std::span exists we should consider using that as the underlying storage for ASCIILiteral since it makes getting the length faster. To make the characters8() function behave as expected we keep a null terminator in the span we hold. * Source/WTF/wtf/text/ASCIILiteral.cpp: (WTF::ASCIILiteral::dump const): * Source/WTF/wtf/text/ASCIILiteral.h: (WTF::StringLiterals::operator _s): (WTF::ASCIILiteral::length const): Deleted. Canonical link: https://commits.webkit.org/277181@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 62b6e2: Fix build issues with latest Clang
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 62b6e2db547e1876be1a5e5e51676839fd58e46e https://github.com/WebKit/WebKit/commit/62b6e2db547e1876be1a5e5e51676839fd58e46e Author: Keith Miller Date: 2024-07-05 (Fri, 05 Jul 2024) Changed paths: M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.cpp M Source/JavaScriptCore/llint/LLIntData.h M Source/JavaScriptCore/parser/Nodes.h M Source/JavaScriptCore/runtime/JSCast.h M Source/ThirdParty/libwebrtc/Source/third_party/boringssl/src/crypto/bio/connect.c M Source/WTF/wtf/cf/TypeCastsCF.h M Source/WebCore/PAL/ThirdParty/libavif/ThirdParty/dav1d/src/decode.c Log Message: --- Fix build issues with latest Clang https://bugs.webkit.org/show_bug.cgi?id=276198 rdar://130933637 Reviewed by Yusuke Suzuki. The use of the template keyword to reference template members without a template argument list was deprecated in the C++ standard. e.g. `foo.template bar()` nows needs to be `foo.template bar<>()`. I ran into a different issue with `std::reference_wrapper` that blocked me from going any further, which AFAICT is a bug on the Clang side. This also fixes a few other warnings that popped up while building with the new Clang denoted inline * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): Clang didn't like the implicit static_cast(UINT32_MAX) so make it explicit with a static_assert no data was lost. * Source/JavaScriptCore/jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitNonNullDecodeZeroExtendedStructureID): Clang didn't like the implicit static_cast(UINT32_MAX) so make it explicit with a static_assert no data was lost. * Source/JavaScriptCore/llint/InPlaceInterpreter.cpp: * Source/JavaScriptCore/llint/LLIntData.h: (JSC::LLInt::getCodeFunctionPtr): (JSC::LLInt::getWide16CodeFunctionPtr): (JSC::LLInt::getWide32CodeFunctionPtr): * Source/JavaScriptCore/parser/Nodes.h: Missing definition of ModuleScopeData added include. * Source/JavaScriptCore/runtime/JSCast.h: (JSC::JSCastingHelpers::inherits): (JSC::jsDynamicCast): * Source/ThirdParty/libwebrtc/Source/third_party/boringssl/src/crypto/bio/connect.c: (conn_callback_ctrl): Had a warning about an incompatible function type. Seems like this is intentional suppressed the warning. * Source/WTF/wtf/cf/TypeCastsCF.h: Had a warning about extra namespace qualification. I just moved it out of the namespace. That said, it feels like this warning shouldn't apply to macro expansions... * Source/WebCore/PAL/ThirdParty/libavif/ThirdParty/dav1d/src/decode.c: (decode_b): Had a warning about different types on the middle/right of a ternary expression. I just pushed the comparison inside the ternary. Canonical link: https://commits.webkit.org/280700@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] b945d5: [WTF] Add Invocable concept for callbacks and star...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b945d56c49fadf2d353b34095e062236fa5ea119 https://github.com/WebKit/WebKit/commit/b945d56c49fadf2d353b34095e062236fa5ea119 Author: Keith Miller Date: 2024-07-14 (Sun, 14 Jul 2024) Changed paths: M Source/JavaScriptCore/b3/B3LowerToAir.cpp M Source/JavaScriptCore/b3/B3LowerToAir32_64.cpp M Source/JavaScriptCore/dfg/DFGTierUpCheckInjectionPhase.cpp M Source/WTF/wtf/FixedVector.h M Source/WTF/wtf/FunctionTraits.h M Source/WTF/wtf/HashMap.h M Source/WTF/wtf/HashSet.h M Source/WTF/wtf/HashTable.h M Source/WTF/wtf/ListHashSet.h M Source/WTF/wtf/LocklessBag.h M Source/WTF/wtf/PriorityQueue.h M Source/WTF/wtf/RobinHoodHashTable.h M Source/WTF/wtf/StdLibExtras.h M Source/WTF/wtf/TinyPtrSet.h M Source/WTF/wtf/Vector.h M Source/WTF/wtf/glib/SysprofAnnotator.h M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp M Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp M Source/WebCore/platform/xr/openxr/OpenXRSwapchain.cpp M Source/WebCore/rendering/EventRegion.cpp M Source/WebCore/svg/SVGToOTFFontConversion.cpp M Source/WebCore/workers/service/background-fetch/BackgroundFetchEngine.cpp M Source/WebCore/workers/service/background-fetch/BackgroundFetchManager.cpp M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp M Source/WebKit/Platform/IPC/ThreadSafeObjectHeap.h M Source/WebKit/UIProcess/DeviceIdHashSaltStorage.cpp M Tools/TestWebKitAPI/Tests/WTF/HashMap.cpp M Tools/TestWebKitAPI/Tests/WTF/RobinHoodHashMap.cpp Log Message: --- [WTF] Add Invocable concept for callbacks and start adoption https://bugs.webkit.org/show_bug.cgi?id=275398 rdar://129668606 Reviewed by Yusuke Suzuki. Right now in WebKit if you want to have a callback the standard practice is to write your function as: `template foo(const Functor& callback)` or `foo(const auto& callback)` this tends to make it unclear what the expected signature of the callback is. Now that we have concepts it would have been nice to do something like: `foo(const std::invocable<...> auto& callback)` however that doesn't provide a clean way to declare the return type, as far as I could tell. This patch adds a new concept to WTF, which should, make this a bit cleaner, `Invocable`. Invocable can be used like the following: `foo(const Invocable auto& callback)` This allows us to use function declaration like syntax to tell folks what type of callback we're expecting. In the process of adding Invocable concepts to arguments there were two other notable changes: 1) HashTable/Map/Set took functions by r-value reference, which seemed weird so I tried changing it. I then noticed that a lot of users of `ensure` were passing lambdas that capture variables by copy rather than reference. Since `ensure`'s use of the lambda is scoped to the call there's no reason to copy data in. 2) the HashTranslator versions of add now take a callback rather than a arbitrary r-value reference type. This makes the logic of the code a bit easier to follow and allows adding invocable concepts. Since the new wrapper lambdas are marked ALWAYS_INLINE_LAMBDA there shouldn't be any performance overhead. * Source/JavaScriptCore/b3/B3LowerToAir.cpp: * Source/JavaScriptCore/b3/B3LowerToAir32_64.cpp: * Source/JavaScriptCore/dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): * Source/WTF/wtf/FixedVector.h: * Source/WTF/wtf/FunctionTraits.h: * Source/WTF/wtf/HashMap.h: (WTF::HashMapTranslator::hash): (WTF::HashMapTranslator::equal): (WTF::HashMapTranslator::translate): (WTF::HashMapEnsureTranslator::hash): (WTF::HashMapEnsureTranslator::equal): (WTF::HashMapEnsureTranslator::translate): (WTF::HashMapTranslatorAdapter::hash): (WTF::HashMapTranslatorAdapter::equal): (WTF::HashMapTranslatorAdapter::translate): (WTF::HashMapEnsureTranslatorAdapter::hash): (WTF::HashMapEnsureTranslatorAdapter::equal): (WTF::HashMapEnsureTranslatorAdapter::translate): (WTF::TableTraitsArg>::inlineAdd): (WTF::TableTraitsArg>::inlineEnsure): (WTF::TableTraitsArg>::ensure): (WTF::TableTraitsArg>::add): (WTF::Y>::removeIf): * Source/WTF/wtf/HashSet.h: (WTF::HashSetTranslator::hash): (WTF::HashSetTranslator::equal): (WTF::HashSetTranslator::translate): (WTF::HashSetTranslatorAdapter::hash): (WTF::HashSetTranslatorAdapter::equal): (WTF::HashSetTranslatorAdapter::translate): (WTF::HashSetEnsureTranslatorAdaptor::hash): (WTF::HashSetEnsureTranslatorAdaptor::equal): (WTF::HashSetEnsureTranslatorAdaptor::translate): (WTF::TableTraits>::ensure): (WTF::TableTraits>::add): (WTF::W>::removeIf): * Source/WTF/wtf/HashTable.h: (WTF::IdentityHashTranslator::hash): (WTF::IdentityHashTranslator::equal): (WTF::IdentityHashTranslator::translate): (WTF::HashTable::add): (WTF::KeyTraits
[webkit-changes] [WebKit/WebKit] 6b7f74: Merge Wasm::Instance into JSWebAssemblyInstance
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 6b7f7447287dd93b8742b5e24ab12047cf6edf48 https://github.com/WebKit/WebKit/commit/6b7f7447287dd93b8742b5e24ab12047cf6edf48 Author: Keith Miller Date: 2024-07-23 (Tue, 23 Jul 2024) Changed paths: M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/bytecode/CodeBlock.h M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/heap/CellAttributes.h M Source/JavaScriptCore/heap/Heap.cpp M Source/JavaScriptCore/heap/IsoCellSet.cpp M Source/JavaScriptCore/heap/IsoCellSet.h M Source/JavaScriptCore/heap/IsoCellSetInlines.h M Source/JavaScriptCore/heap/IsoSubspace.cpp M Source/JavaScriptCore/heap/IsoSubspace.h M Source/JavaScriptCore/heap/IsoSubspaceInlines.h M Source/JavaScriptCore/heap/IsoSubspacePerVM.cpp M Source/JavaScriptCore/heap/LocalAllocator.cpp M Source/JavaScriptCore/heap/MarkedBlock.h M Source/JavaScriptCore/heap/MarkedSpace.cpp M Source/JavaScriptCore/heap/PreciseAllocation.cpp M Source/JavaScriptCore/heap/PreciseAllocation.h M Source/JavaScriptCore/heap/Subspace.h M Source/JavaScriptCore/interpreter/CallFrame.cpp M Source/JavaScriptCore/interpreter/CallFrame.h M Source/JavaScriptCore/interpreter/CallFrameInlines.h M Source/JavaScriptCore/interpreter/Interpreter.cpp M Source/JavaScriptCore/interpreter/ProtoCallFrame.h M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/JITCode.h M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/llint/InPlaceInterpreter64.asm M Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/llint/WebAssembly.asm M Source/JavaScriptCore/llint/WebAssembly32_64.asm M Source/JavaScriptCore/llint/WebAssembly64.asm M Source/JavaScriptCore/runtime/JSCell.cpp M Source/JavaScriptCore/runtime/JSCell.h M Source/JavaScriptCore/runtime/Structure.h M Source/JavaScriptCore/runtime/VM.cpp M Source/JavaScriptCore/runtime/VM.h M Source/JavaScriptCore/runtime/WeakGCSet.h M Source/JavaScriptCore/runtime/WeakGCSetInlines.h M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT.h M Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp M Source/JavaScriptCore/wasm/WasmBinding.cpp M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmCallee.h M Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp M Source/JavaScriptCore/wasm/WasmConstExprGenerator.h M Source/JavaScriptCore/wasm/WasmContext.h M Source/JavaScriptCore/wasm/WasmGlobal.h M Source/JavaScriptCore/wasm/WasmHandlerInfo.cpp M Source/JavaScriptCore/wasm/WasmHandlerInfo.h M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h M Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h R Source/JavaScriptCore/wasm/WasmInstance.cpp R Source/JavaScriptCore/wasm/WasmInstance.h M Source/JavaScriptCore/wasm/WasmJS.h M Source/JavaScriptCore/wasm/WasmMemory.cpp M Source/JavaScriptCore/wasm/WasmMemory.h M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmOperations.h M Source/JavaScriptCore/wasm/WasmOperationsInlines.h M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmSlowPaths.h M Source/JavaScriptCore/wasm/WasmTable.cpp M Source/JavaScriptCore/wasm/WasmTable.h M Source/JavaScriptCore/wasm/WasmThunks.cpp M Source/JavaScriptCore/wasm/js/JSToWasm.cpp M Source/JavaScriptCore/wasm/js/JSWebAssembly.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h M Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.h M Source/JavaScriptCore/wasm/js/JSWebAssemblyStruct.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.cpp M Source/JavaScriptCore/wasm/js/WasmToJS.cpp M Source/JavaScriptCore/wasm/js/WasmToJS.h M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyInstanceConstructor.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyWrapperFunction.cpp M Source/WebCore/bindings/js/SerializedScriptValue.cpp Log Message: --- Merge Wasm::Instance into JSWebAssemblyInstance https://bugs.webkit.org/show_bug.cgi?id=276963 rdar://problem/132330783 Reviewed by Yusuke
[webkit-changes] [WebKit/WebKit] b7de8d: Merge Wasm::Instance into JSWebAssemblyInstance
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b7de8d58745394254579958957e487a7a38b4b0b https://github.com/WebKit/WebKit/commit/b7de8d58745394254579958957e487a7a38b4b0b Author: Keith Miller Date: 2024-07-24 (Wed, 24 Jul 2024) Changed paths: M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/bytecode/CodeBlock.h M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/heap/CellAttributes.h M Source/JavaScriptCore/heap/Heap.cpp M Source/JavaScriptCore/heap/IsoCellSet.cpp M Source/JavaScriptCore/heap/IsoCellSet.h M Source/JavaScriptCore/heap/IsoCellSetInlines.h M Source/JavaScriptCore/heap/IsoSubspace.cpp M Source/JavaScriptCore/heap/IsoSubspace.h M Source/JavaScriptCore/heap/IsoSubspaceInlines.h M Source/JavaScriptCore/heap/IsoSubspacePerVM.cpp M Source/JavaScriptCore/heap/LocalAllocator.cpp M Source/JavaScriptCore/heap/MarkedBlock.h M Source/JavaScriptCore/heap/MarkedSpace.cpp M Source/JavaScriptCore/heap/PreciseAllocation.cpp M Source/JavaScriptCore/heap/PreciseAllocation.h M Source/JavaScriptCore/heap/Subspace.h M Source/JavaScriptCore/interpreter/CallFrame.cpp M Source/JavaScriptCore/interpreter/CallFrame.h M Source/JavaScriptCore/interpreter/CallFrameInlines.h M Source/JavaScriptCore/interpreter/Interpreter.cpp M Source/JavaScriptCore/interpreter/ProtoCallFrame.h M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/JITCode.h M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/llint/InPlaceInterpreter64.asm M Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/llint/WebAssembly.asm M Source/JavaScriptCore/llint/WebAssembly32_64.asm M Source/JavaScriptCore/llint/WebAssembly64.asm M Source/JavaScriptCore/runtime/JSCell.cpp M Source/JavaScriptCore/runtime/JSCell.h M Source/JavaScriptCore/runtime/Structure.h M Source/JavaScriptCore/runtime/VM.cpp M Source/JavaScriptCore/runtime/VM.h M Source/JavaScriptCore/runtime/WeakGCSet.h M Source/JavaScriptCore/runtime/WeakGCSetInlines.h M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT.h M Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp M Source/JavaScriptCore/wasm/WasmBinding.cpp M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmCallee.h M Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp M Source/JavaScriptCore/wasm/WasmConstExprGenerator.h M Source/JavaScriptCore/wasm/WasmContext.h M Source/JavaScriptCore/wasm/WasmGlobal.h M Source/JavaScriptCore/wasm/WasmHandlerInfo.cpp M Source/JavaScriptCore/wasm/WasmHandlerInfo.h M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h M Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h R Source/JavaScriptCore/wasm/WasmInstance.cpp R Source/JavaScriptCore/wasm/WasmInstance.h M Source/JavaScriptCore/wasm/WasmJS.h M Source/JavaScriptCore/wasm/WasmMemory.cpp M Source/JavaScriptCore/wasm/WasmMemory.h M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmOperations.h M Source/JavaScriptCore/wasm/WasmOperationsInlines.h M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmSlowPaths.h M Source/JavaScriptCore/wasm/WasmTable.cpp M Source/JavaScriptCore/wasm/WasmTable.h M Source/JavaScriptCore/wasm/WasmThunks.cpp M Source/JavaScriptCore/wasm/js/JSToWasm.cpp M Source/JavaScriptCore/wasm/js/JSWebAssembly.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h M Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.h M Source/JavaScriptCore/wasm/js/JSWebAssemblyStruct.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.cpp M Source/JavaScriptCore/wasm/js/WasmToJS.cpp M Source/JavaScriptCore/wasm/js/WasmToJS.h M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyInstanceConstructor.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyWrapperFunction.cpp M Source/WebCore/bindings/js/SerializedScriptValue.cpp Log Message: --- Merge Wasm::Instance into JSWebAssemblyInstance https://bugs.webkit.org/show_bug.cgi?id=276963 rdar://problem/132330783 Reviewed by Yusuke
[webkit-changes] [WebKit/WebKit] baa1f6: Unreviewed, remove incorrect ASSERTs from JSWebAss...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: baa1f6e6d54822d857308d2afa5f20d978dd0df0 https://github.com/WebKit/WebKit/commit/baa1f6e6d54822d857308d2afa5f20d978dd0df0 Author: Keith Miller Date: 2024-07-25 (Thu, 25 Jul 2024) Changed paths: A JSTests/wasm/stress/cross-realm-webassembly-instances.js M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp Log Message: --- Unreviewed, remove incorrect ASSERTs from JSWebAssemblyInstance https://bugs.webkit.org/show_bug.cgi?id=277073 The ASSERT(globalObject == this->globalObject()) isn't true when there's a newTarget * JSTests/wasm/stress/cross-realm-webassembly-instances.js: Added. (const.getNewTargets): (test): (assert_equal): (constructorArg.of.interfaces.testDescription.of.getNewTargets): * Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::initializeImports): (JSC::JSWebAssemblyInstance::finalizeCreation): Canonical link: https://commits.webkit.org/281347@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] f9def5: Remove JSWebAssemblyInstance anchoring
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: f9def56810e259e539cac8f9147407d0d5028561 https://github.com/WebKit/WebKit/commit/f9def56810e259e539cac8f9147407d0d5028561 Author: Keith Miller Date: 2024-07-25 (Thu, 25 Jul 2024) Changed paths: M Source/JavaScriptCore/assembler/AbstractMacroAssembler.h M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/llint/WebAssembly.asm M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT.h M Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp Log Message: --- Remove JSWebAssemblyInstance anchoring https://bugs.webkit.org/show_bug.cgi?id=277082 rdar://problem/132492386 Reviewed by Justin Michaud and Yusuke Suzuki. Now that Wasm::Instance has been merged with JSWebAssemblyInstance we no longer need to anchor the JSCell for GC. This patch removes most of that unneeded code. At the same time I made two other changes: 1) Fix a bug OMGs tail call generation where it forgot to add the old frame size when "restoring" sp for pointer authentication. 2) Elide emitting transfer instructions when src and dest are the same. To do this a default operator== was added to Address and BaseIndex. * Source/JavaScriptCore/assembler/AbstractMacroAssembler.h: * Source/JavaScriptCore/assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::transfer32): (JSC::MacroAssemblerARM64::transfer64): (JSC::MacroAssemblerARM64::transferVector): * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * Source/JavaScriptCore/llint/WebAssembly.asm: * Source/JavaScriptCore/wasm/WasmBBQJIT.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::emitIndirectCall): (JSC::Wasm::BBQJITImpl::BBQJIT::addCallIndirect): * Source/JavaScriptCore/wasm/WasmBBQJIT.h: * Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addCallRef): * Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addCallRef): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp: (JSC::Wasm::OMGIRGenerator::emitIndirectCall): (JSC::Wasm::OMGIRGenerator::createCallPatchpoint): (JSC::Wasm::prepareForTailCallImpl): (JSC::Wasm::OMGIRGenerator::addCall): (JSC::Wasm::OMGIRGenerator::addCallIndirect): (JSC::Wasm::OMGIRGenerator::addCallRef): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp: (JSC::Wasm::OMGIRGenerator::emitIndirectCall): (JSC::Wasm::OMGIRGenerator::addCall): * Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::WebAssemblyFunction::jsCallEntrypointSlow): Canonical link: https://commits.webkit.org/281356@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] f8d5c1: Rename WebAssembly JSC options to Wasm
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: f8d5c15c07d820de1adb9b11f5923d9e8479565d https://github.com/WebKit/WebKit/commit/f8d5c15c07d820de1adb9b11f5923d9e8479565d Author: Keith Miller Date: 2024-07-27 (Sat, 27 Jul 2024) Changed paths: M JSTests/microbenchmarks/exceptions-simd.js M JSTests/microbenchmarks/wasm-cc-int-to-int.js M JSTests/wasm/extended-const/extended-const.js M JSTests/wasm/extended-const/flag-turned-off.js M JSTests/wasm/function-references/block_signature.js M JSTests/wasm/function-references/br_on_null.js M JSTests/wasm/function-references/bug243265.js M JSTests/wasm/function-references/call_ref.js M JSTests/wasm/function-references/local_init.js M JSTests/wasm/function-references/ref_as_non_null.js M JSTests/wasm/function-references/ref_types.js M JSTests/wasm/function-references/table.js M JSTests/wasm/function-references/table_init.js M JSTests/wasm/gc/any.js M JSTests/wasm/gc/array_new_data.js M JSTests/wasm/gc/array_new_elem.js M JSTests/wasm/gc/array_new_fixed.js M JSTests/wasm/gc/array_new_fixed_long.js M JSTests/wasm/gc/arrays.js M JSTests/wasm/gc/block.js M JSTests/wasm/gc/br_on_cast.js M JSTests/wasm/gc/bug247874.js M JSTests/wasm/gc/bug250613.js M JSTests/wasm/gc/bug252299.js M JSTests/wasm/gc/bug252538.js M JSTests/wasm/gc/bug252719.js M JSTests/wasm/gc/bug254226.js M JSTests/wasm/gc/bug254412.js M JSTests/wasm/gc/bug254413.js M JSTests/wasm/gc/bug254414.js M JSTests/wasm/gc/bug258127.js M JSTests/wasm/gc/bug258128.js M JSTests/wasm/gc/bug258499.js M JSTests/wasm/gc/bug258795.js M JSTests/wasm/gc/bug258796.js M JSTests/wasm/gc/bug258801.js M JSTests/wasm/gc/bug258804.js M JSTests/wasm/gc/bug258805.js M JSTests/wasm/gc/bug260516.js M JSTests/wasm/gc/bug262862.js M JSTests/wasm/gc/bug262863.js M JSTests/wasm/gc/bug265721.js M JSTests/wasm/gc/bug265742.js M JSTests/wasm/gc/bug265927.js M JSTests/wasm/gc/bug266043.js M JSTests/wasm/gc/bug266056.js M JSTests/wasm/gc/bug266127.js M JSTests/wasm/gc/bug266167.js M JSTests/wasm/gc/bug266249.js M JSTests/wasm/gc/bug267381.js M JSTests/wasm/gc/bulk-array.js M JSTests/wasm/gc/call_indirect.js M JSTests/wasm/gc/call_ref.js M JSTests/wasm/gc/casts.js M JSTests/wasm/gc/const-exprs-flag-off.js M JSTests/wasm/gc/const-exprs.js M JSTests/wasm/gc/eq.js M JSTests/wasm/gc/exception.js M JSTests/wasm/gc/extern.js M JSTests/wasm/gc/i31.js M JSTests/wasm/gc/js-api.js M JSTests/wasm/gc/limits.js M JSTests/wasm/gc/linking.js M JSTests/wasm/gc/packed-arrays.js M JSTests/wasm/gc/rec.js M JSTests/wasm/gc/simd.js M JSTests/wasm/gc/structs.js M JSTests/wasm/gc/sub.js M JSTests/wasm/gc/subtyping.js M JSTests/wasm/gc/table_init.js M JSTests/wasm/ipint-tests/perf.py M JSTests/wasm/references/element_active_mod.js M JSTests/wasm/references/func_ref.js M JSTests/wasm/references/is_null.js M JSTests/wasm/references/table_misc.js M JSTests/wasm/references/validation.js M JSTests/wasm/regress/llint-callee-saves-with-fast-memory.js M JSTests/wasm/regress/llint-callee-saves-without-fast-memory.js M JSTests/wasm/stress/big-try-simd.js M JSTests/wasm/stress/big-try.js M JSTests/wasm/stress/big-tuple-args.js M JSTests/wasm/stress/big-tuple.js M JSTests/wasm/stress/cc-int-to-int-cross-module-with-exception.js M JSTests/wasm/stress/cc-int-to-int-jit-to-llint.js M JSTests/wasm/stress/cc-int-to-int-no-jit.js M JSTests/wasm/stress/cc-int-to-int-tail-call.js M JSTests/wasm/stress/dont-stack-overflow-in-air.js M JSTests/wasm/stress/simd-big-tuple.js M JSTests/wasm/stress/simd-const-relaxed-f32-madd.js M JSTests/wasm/stress/simd-const-relaxed-f32-trunc.js M JSTests/wasm/stress/simd-const-relaxed-f64-madd.js M JSTests/wasm/stress/simd-const-relaxed-f64-trunc.js M JSTests/wasm/stress/simd-const-relaxed-swizzle.js M JSTests/wasm/stress/simd-const-spill.js M JSTests/wasm/stress/simd-const.js M JSTests/wasm/stress/simd-exception-throwing-v128-clobbers-fp.js M JSTests/wasm/stress/simd-exception.js M JSTests/wasm/stress/simd-global-get.js M JSTests/wasm/stress/simd-global-set.js M JSTests/wasm/stress/simd-import-global-2.js M JSTests/wasm/stress/simd-kitchen-sink.js M JSTests/wasm/stress/simd-load.js M JSTests/wasm/stress/simd-no-fast-mem-load-lane.js M JSTests/wasm/stress/simd-no-fast-mem-load-splat.js M JSTests/wasm/stress/simd-no-fast-mem-store-lane.js M JSTests/wasm/stress/simd-osr-many-vectors.js M JSTests/wasm/stress/simd-osr.js M JSTests/wasm/stress/simd-regalloc-stress-2.js M JSTests/wasm/stress/simd-regalloc-stress.js M JSTests/wasm/stress/simd-register-allocation.js M JSTests/wasm
[webkit-changes] [WebKit/WebKit] 7c8243: Add WASM tail calls support to single-pass BBQ JIT
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 7c8243bd28578162b7de09d3e7896547bb28a2e1 https://github.com/WebKit/WebKit/commit/7c8243bd28578162b7de09d3e7896547bb28a2e1 Author: Keith Miller Date: 2024-07-31 (Wed, 31 Jul 2024) Changed paths: M JSTests/wasm/stress/cc-int-to-int-memory.js M JSTests/wasm/stress/cc-int-to-int-tail-call.js M JSTests/wasm/stress/simd-tail-call-simple.js M JSTests/wasm/stress/simd-tail-calls-throw.js M JSTests/wasm/stress/tail-call-double.js M JSTests/wasm/stress/tail-call-js-inline.js M JSTests/wasm/stress/tail-call-js.js M JSTests/wasm/stress/tail-call-should-not-clobber-caller-origin.js M JSTests/wasm/stress/tail-call-simple.js M Source/JavaScriptCore/assembler/MacroAssembler.h M Source/JavaScriptCore/assembler/MacroAssemblerPrinter.h M Source/JavaScriptCore/runtime/Options.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT.h M Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp M Source/JavaScriptCore/wasm/WasmCallingConvention.h M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp Log Message: --- Add WASM tail calls support to single-pass BBQ JIT https://bugs.webkit.org/show_bug.cgi?id=253192 rdar://106448393 Reviewed by Justin Michaud and Yusuke Suzuki. This is an old patch that I've had sitting around for a while but never got around to uploading. I put the tail call emit functions in their own function since they are subtly different enough from the non-tail call versions it seemed more complicated to combine them. The main other interesting detail is that on x86_64 we don't have enough non-argument caller-save registers to hold the save FP/return PC. This means they get shuffled with the other parameters and then get popped later once the shuffle is done. * JSTests/wasm/stress/cc-int-to-int-memory.js: * JSTests/wasm/stress/cc-int-to-int-tail-call.js: * JSTests/wasm/stress/simd-tail-call-simple.js: * JSTests/wasm/stress/simd-tail-calls-throw.js: * JSTests/wasm/stress/tail-call-double.js: * JSTests/wasm/stress/tail-call-js-inline.js: * JSTests/wasm/stress/tail-call-js.js: * JSTests/wasm/stress/tail-call-should-not-clobber-caller-origin.js: * JSTests/wasm/stress/tail-call-simple.js: * JSTests/wasm/tail-call-spec-tests/tail_call_indirect.wast.js: * Source/JavaScriptCore/assembler/MacroAssembler.h: * Source/JavaScriptCore/assembler/MacroAssemblerPrinter.h: (JSC::MacroAssembler::println): (JSC::AllRegisters::AllRegisters): Deleted. (JSC::Memory::Memory): Deleted. (JSC::MemWord::MemWord): Deleted. * Source/JavaScriptCore/runtime/Options.cpp: (JSC::Options::notifyOptionsChanged): * Source/JavaScriptCore/wasm/WasmBBQJIT.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addTopLevel): (JSC::Wasm::BBQJITImpl::BBQJIT::emitTailCall): (JSC::Wasm::BBQJITImpl::BBQJIT::addCall): (JSC::Wasm::BBQJITImpl::BBQJIT::emitIndirectCall): (JSC::Wasm::BBQJITImpl::BBQJIT::emitIndirectTailCall): (JSC::Wasm::BBQJITImpl::BBQJIT::addCallIndirect): * Source/JavaScriptCore/wasm/WasmBBQJIT.h: (JSC::Wasm::BBQJITImpl::BBQJIT::ScratchScope::initializedPreservedSet): * Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addCallRef): * Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addCallRef): * Source/JavaScriptCore/wasm/WasmCallingConvention.h: (JSC::Wasm::WasmCallingConvention::argumentGPRS const): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp: (JSC::Wasm::OMGIRGenerator::createTailCallPatchpoint): * Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): Canonical link: https://commits.webkit.org/281656@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] c37cef: Reduce JSC EWS false positives
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c37cef3423f75c0c378eb148ec66dbf374cd1655 https://github.com/WebKit/WebKit/commit/c37cef3423f75c0c378eb148ec66dbf374cd1655 Author: Keith Miller Date: 2024-07-31 (Wed, 31 Jul 2024) Changed paths: M Tools/CISupport/ews-build/steps.py Log Message: --- Reduce JSC EWS false positives https://bugs.webkit.org/show_bug.cgi?id=277428 rdar://132910943 Reviewed by Aakash Jain, Yusuke Suzuki and Mark Lam. Right now JSC EWS triggers when files such as JSCSSRuleCustom.cpp are modified because anything with jsc in the path are considered relevant. In practice our `.*javascriptcore.*` will catch anything in `Source/JavaScriptCore` and we only care about `.*jsc.*` when its inside `Tools/` This also adds a pattern for `LayoutTests/js` since those tests run in the JSC harness too. * Tools/CISupport/ews-build/steps.py: (CheckChangeRelevance): Canonical link: https://commits.webkit.org/281668@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] bf6e09: REGRESSION(281024@main) LLInt return locations nee...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: bf6e09860923b5dbb3392137c6a2932b4285e01e https://github.com/WebKit/WebKit/commit/bf6e09860923b5dbb3392137c6a2932b4285e01e Author: Keith Miller Date: 2024-07-31 (Wed, 31 Jul 2024) Changed paths: M Source/JavaScriptCore/assembler/JITOperationList.cpp M Source/JavaScriptCore/llint/LLIntOpcode.h M Source/JavaScriptCore/llint/LLIntThunks.cpp Log Message: --- REGRESSION(281024@main) LLInt return locations need to be added to JITOperationList https://bugs.webkit.org/show_bug.cgi?id=277462 rdar://132951616 Reviewed by Alexey Shvayka. Move the list of LLInt opcodes that need returns to a macro so they get automagically populated into JITOperationList. * Source/JavaScriptCore/assembler/JITOperationList.cpp: (JSC::llintOperations): * Source/JavaScriptCore/llint/LLIntOpcode.h: * Source/JavaScriptCore/llint/LLIntThunks.cpp: (JSC::LLInt::returnLocationThunk): Canonical link: https://commits.webkit.org/281685@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] c3a1ba: Enable wasm tail calls
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c3a1babc1e75481763edce5a9e46cb66c15639b8 https://github.com/WebKit/WebKit/commit/c3a1babc1e75481763edce5a9e46cb66c15639b8 Author: Keith Miller Date: 2024-08-01 (Thu, 01 Aug 2024) Changed paths: A JSTests/wasm/stress/tail-call-indirect-parameters-on-stack.js A JSTests/wasm/stress/tail-call-parameters-on-stack.js M JSTests/wasm/stress/tail-call.js M Source/JavaScriptCore/runtime/OptionsList.h Log Message: --- Enable wasm tail calls https://bugs.webkit.org/show_bug.cgi?id=277445 rdar://131410516 Reviewed by Yusuke Suzuki. This patch adds two new test files that were failing before. It also removes the testStackOverflow case from tail-call.js because it incorrectly assumed that a tail call would always be possible even when at the soft stack limit. * JSTests/wasm/stress/tail-call-indirect-parameters-on-stack.js: Added. (from.string_appeared_here.import.as.assert.from.string_appeared_here.let.wat.module.type.f2_sig.func.param.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.result.i32.table.1.funcref.func.f1.export.string_appeared_here.param.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.result.i32.local.0.local.1.local.2.local.3.local.4.local.5.local.6.local.7.local.8.local.9.local.10.i32.const.100.i32.const.200.i32.const.300.i32.const.0.return_call_indirect.type.f2_sig.func.f2.type.f2_sig.local.0.local.1.local.2.local.3.local.4.local.5.local.6.local.7.local.8.local.9.local.10.local.11.local.12.local.13.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.elem.i32.const.0.f2.async test): * JSTests/wasm/stress/tail-call-parameters-on-stack.js: Added. (from.string_appeared_here.import.as.assert.from.string_appeared_here.let.wat.module.func.f1.export.string_appeared_here.param.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.result.i32.local.0.local.1.local.2.local.3.local.4.local.5.local.6.local.7.local.8.local.9.local.10.i32.const.100.i32.const.200.i32.const.300.return_call.f2.func.f2.param.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.i32.result.i32.local.0.local.1.local.2.local.3.local.4.local.5.local.6.local.7.local.8.local.9.local.10.local.11.local.12.local.13.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.i32.add.async test): * JSTests/wasm/stress/tail-call.js: (const.testStackOverflow): Deleted. Canonical link: https://commits.webkit.org/281716@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] f5716c: Add mechanism to automatically convert Enums to St...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: f5716c3f9c9a8b19d82c02df456588ea62767c1e https://github.com/WebKit/WebKit/commit/f5716c3f9c9a8b19d82c02df456588ea62767c1e Author: Keith Miller Date: 2024-08-05 (Mon, 05 Aug 2024) Changed paths: M JSTests/wasm/wabt-wrapper.js M Source/JavaScriptCore/bytecode/ExitKind.cpp M Source/JavaScriptCore/bytecode/ExitKind.h M Source/JavaScriptCore/bytecode/ExpressionInfo.cpp M Source/JavaScriptCore/bytecode/ExpressionInfo.h M Source/JavaScriptCore/bytecode/Watchpoint.h M Source/JavaScriptCore/dfg/DFGArrayMode.cpp M Source/JavaScriptCore/dfg/DFGArrayMode.h M Source/JavaScriptCore/dfg/DFGBranchDirection.h M Source/JavaScriptCore/dfg/DFGOSRExit.cpp M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp M Source/JavaScriptCore/heap/AbstractSlotVisitor.h M Source/JavaScriptCore/heap/AlignedMemoryAllocator.h M Source/JavaScriptCore/heap/GCLogging.cpp M Source/JavaScriptCore/heap/GCLogging.h M Source/JavaScriptCore/heap/GigacageAlignedMemoryAllocator.cpp M Source/JavaScriptCore/jit/JITOpaqueByproduct.h M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/profiler/ProfilerOSRExit.cpp M Source/JavaScriptCore/runtime/BufferMemoryHandle.cpp M Source/JavaScriptCore/runtime/BufferMemoryHandle.h M Source/JavaScriptCore/runtime/Options.cpp M Source/JavaScriptCore/wasm/WasmWorklist.cpp M Source/JavaScriptCore/wasm/WasmWorklist.h M Source/WTF/wtf/EnumTraits.h M Source/WTF/wtf/Gigacage.h M Source/WTF/wtf/PrintStream.h M Tools/TestWebKitAPI/Configurations/DebugRelease.xcconfig M Tools/TestWebKitAPI/Tests/WTF/EnumTraits.cpp Log Message: --- Add mechanism to automatically convert Enums to Strings for printing https://bugs.webkit.org/show_bug.cgi?id=271967 rdar://125723369 Reviewed by Yusuke Suzuki. This patch adds support a set of new functions that return a `std::span` with the stringification of an enum's type or members. Members are determined by reflecting on the compiler's result for `__PRETTY_FUNCTION__`. This doesn't seem to significantly increase compile times as a Debug build of JSC was 272.5s with this change vs 268.8s without (~1% compile time increase). In order to limit compile time overhead, the number of enum values stringified is limited to 256 by default. This patch also integrates this new name reflection into `dataLog` so it will automatically print the enum's value strigified into the log. There's also a `ScopedEnumDump` that includes the enum's name and `EnumDumpWithDefault` that takes a default string if a stringification for the enum value can't be deduced. * JSTests/wasm/wabt-wrapper.js: * Source/JavaScriptCore/bytecode/ExitKind.cpp: (JSC::exitKindToString): Deleted. (WTF::printInternal): Deleted. * Source/JavaScriptCore/bytecode/ExitKind.h: * Source/JavaScriptCore/bytecode/ExpressionInfo.cpp: (WTF::printInternal): Deleted. * Source/JavaScriptCore/bytecode/ExpressionInfo.h: * Source/JavaScriptCore/dfg/DFGArrayMode.cpp: (WTF::printInternal): (JSC::DFG::arrayActionToString): Deleted. (JSC::DFG::arrayTypeToString): Deleted. (JSC::DFG::arrayClassToString): Deleted. (JSC::DFG::arraySpeculationToString): Deleted. (JSC::DFG::arrayConversionToString): Deleted. * Source/JavaScriptCore/dfg/DFGArrayMode.h: * Source/JavaScriptCore/dfg/DFGBranchDirection.h: (JSC::DFG::branchDirectionToString): Deleted. (WTF::printInternal): Deleted. * Source/JavaScriptCore/dfg/DFGOSRExit.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * Source/JavaScriptCore/heap/GCLogging.cpp: (JSC::GCLogging::levelAsString): Deleted. * Source/JavaScriptCore/heap/GCLogging.h: * Source/JavaScriptCore/jsc.cpp: (CommandLine::parseArguments): * Source/JavaScriptCore/profiler/ProfilerOSRExit.cpp: (JSC::Profiler::OSRExit::toJSON const): * Source/JavaScriptCore/runtime/BufferMemoryHandle.cpp: (JSC::BufferMemoryResult::dump const): (JSC::BufferMemoryManager::tryAllocatePhysicalBytes): (JSC::BufferMemoryResult::toString): Deleted. * Source/JavaScriptCore/runtime/BufferMemoryHandle.h: * Source/JavaScriptCore/runtime/Options.cpp: (JSC::OptionsHelper::Option::dump const): * Source/JavaScriptCore/wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::priorityString): Deleted. * Source/JavaScriptCore/wasm/WasmWorklist.h: * Source/WTF/wtf/EnumTraits.h: (WTF::enumTypeNameImpl): (WTF::enumTypeName): (WTF::enumNameImpl): (WTF::enumName): (WTF::detail::for_constexpr): (WTF::enumNames): * Source/WTF/wtf/Gigacage.h: (Gigacage::name): Deleted. * Source/WTF/wtf/PrintStream.h: (WTF::printInternal): (WTF::ScopedEnumDump::ScopedEnumDump): (WTF::ScopedEnumDump::dump const): (WTF::EnumDumpMayBeUnknown::EnumDumpMayBeUnknown): (WTF::EnumDumpMayBeUnknown::dump const): (WTF::requires): Canonical link: https://commits.webkit.org/281831@main To unsubsc
[webkit-changes] [WebKit/WebKit] 5c9edc: Add a category-breakdown to compare-results
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 5c9edc56375937ca181745a48c0a7e5fa2a95b7a https://github.com/WebKit/WebKit/commit/5c9edc56375937ca181745a48c0a7e5fa2a95b7a Author: Keith Miller Date: 2024-08-05 (Mon, 05 Aug 2024) Changed paths: M Tools/Scripts/compare-results Log Message: --- Add a category-breakdown to compare-results https://bugs.webkit.org/show_bug.cgi?id=277646 rdar://133235581 Reviewed by Yusuke Suzuki. This provides a breakdown per benchamrk category (e.g. Worst, Startup, Average in JetStream2). This looks like: --- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | --- | Average |19.187656 |19.209764 |1.001152 | 0.992457 | | First |32.916071 |32.796429 |0.996365 | 0.969416 | | MainRun |2385.50 |2386.60 |1.000461 | 0.914809 | | Runtime |629.70|632.10|1.003811 | 0.984437 | | Startup |8.14 |3.00 |0.368550 | 0.041433 | | Stdlib |1224.50 |1221.10 |0.997223 | 0.271944 | | Worst |22.904464 |22.745536 |0.993061 | 0.947732 | --- for JetStream2. I only added it to JetStream2/3 since those benchmarks have a lot of different categories. I also changed the script so it will log `--detailed-breakdown` and `--breakdown` if both are passed rather than just `--detailed-breakdown`. * Tools/Scripts/compare-results: (detailedJetStream2Breakdown): (categoryJetStream2Breakdown): (detailedJetStream3Breakdown): (getOptions): (main): Canonical link: https://commits.webkit.org/281867@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] f2ca9c: JSC restricted options should be available by defa...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: f2ca9cb543ab57e3afedba3a6301962af3be4d15 https://github.com/WebKit/WebKit/commit/f2ca9cb543ab57e3afedba3a6301962af3be4d15 Author: Keith Miller Date: 2024-08-06 (Tue, 06 Aug 2024) Changed paths: M Source/JavaScriptCore/Configurations/DebugRelease.xcconfig M Source/JavaScriptCore/runtime/Options.cpp Log Message: --- JSC restricted options should be available by default in development builds https://bugs.webkit.org/show_bug.cgi?id=277689 rdar://133304364 Reviewed by Yusuke Suzuki. Right now it's available when NDEBUG isn't defined (aka Debug builds). But we have an xcconfig specifically for development builds. We can just set a preprocessor flag there so it only shows up for Debug/Release builds and not in Production. * Source/JavaScriptCore/Configurations/DebugRelease.xcconfig: * Source/JavaScriptCore/runtime/Options.cpp: (JSC::Options::initialize): Canonical link: https://commits.webkit.org/281917@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] bb3db1: Merge JetStreamDriver.js changes from JS2 to JS3
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: bb3db1a780028c0d5a9389c51436c4353a3cedf3 https://github.com/WebKit/WebKit/commit/bb3db1a780028c0d5a9389c51436c4353a3cedf3 Author: Keith Miller Date: 2024-08-07 (Wed, 07 Aug 2024) Changed paths: M PerformanceTests/JetStream3/JetStreamDriver.js Log Message: --- Merge JetStreamDriver.js changes from JS2 to JS3 https://bugs.webkit.org/show_bug.cgi?id=277742 rdar://133394269 Reviewed by Yijia Huang. This is mostly silencing prints when dumping to JSON. But also allowing scripts to set customTestList too. * PerformanceTests/JetStream3/JetStreamDriver.js: (Driver.prototype.async start): (prototype.updateUIBeforeRun): (DefaultBenchmark.prototype.updateUIAfterRun): (DefaultBenchmark): (prototype.updateUIAfterRun): (WasmBenchmark.prototype.get runnerCode): Canonical link: https://commits.webkit.org/281946@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] b84e32: [JS3] Use performance instead of Date for timing w...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b84e32b70debb71660f7b258e841f42a2c13746e https://github.com/WebKit/WebKit/commit/b84e32b70debb71660f7b258e841f42a2c13746e Author: Keith Miller Date: 2024-08-08 (Thu, 08 Aug 2024) Changed paths: M PerformanceTests/JetStream3/JetStreamDriver.js M PerformanceTests/JetStream3/cli.js Log Message: --- [JS3] Use performance instead of Date for timing where available https://bugs.webkit.org/show_bug.cgi?id=21 rdar://133411753 Reviewed by Yusuke Suzuki. performance.now has less clamping than Date.now in some browsers when COOP/COEP headers are set. Thus gives a more accurate timing for the benchamrk so we should use performance.now instead. * PerformanceTests/JetStream3/JetStreamDriver.js: (Driver.prototype.async start): (Driver.prototype.runCode): (Driver.prototype.prepareToRun.text.div): (prototype.get runnerCode): (prototype.async run): (AsyncBenchmark.get runnerCode.return.async doRun): (AsyncBenchmark.prototype.get runnerCode): (AsyncBenchmark): * PerformanceTests/JetStream3/cli.js: (async runJetStream): Canonical link: https://commits.webkit.org/281992@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] cb65a1: Defer GC while compiling wasm modules
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: cb65a1a9caa7c9e6dcd70d1548ebf9e354a69031 https://github.com/WebKit/WebKit/commit/cb65a1a9caa7c9e6dcd70d1548ebf9e354a69031 Author: Keith Miller Date: 2024-08-15 (Thu, 15 Aug 2024) Changed paths: M Source/JavaScriptCore/heap/Heap.cpp M Source/JavaScriptCore/heap/Heap.h M Source/JavaScriptCore/heap/SpaceTimeMutatorScheduler.cpp M Source/JavaScriptCore/heap/StochasticSpaceTimeMutatorScheduler.cpp M Source/JavaScriptCore/runtime/VM.cpp M Source/WTF/wtf/PrintStream.h M Source/WebCore/page/OpportunisticTaskScheduler.cpp Log Message: --- Defer GC while compiling wasm modules https://bugs.webkit.org/show_bug.cgi?id=278183 rdar://133973759 Reviewed by Yusuke Suzuki. Right now when we start to compile a wasm module we typically end up allocating a Wasm::Memory. Since Wasm::Memories tend to be VERY large (some multiple of 64KB) this typically triggers a GC. However since most of the additional memory is from a Wasm::Memory, which likely won't be free for a while we don't collect much and spend a lot of critical CPU time GCing. We could have just deferred GC by forcing GC to be deferred but that felt overly aggressive. Instead this patch introduces a concept of oversized allocations which is anything >= 64KB (smaller numbers weren't sufficient). When the last oversized allocation is more than 1/3 of the total bytes allocated this cycle we now defer GC. Just deferring GC from collectIfNecessaryOrDefer was still insufficient to stop GCs during compilation. We also have to force OpportunisticTaskScheduler to defer timer based GCs while wasm compilation is going on. This seems to be a .5-1% JetStream progression and weirdly might also be a RAMification win too. Also seems neutral for other memory tests and Speedometer. * Source/JavaScriptCore/heap/Heap.cpp: (JSC::Heap::reportAbandonedObjectGraph): (JSC::Heap::runBeginPhase): (JSC::Heap::willStartCollection): (JSC::Heap::updateAllocationLimits): (JSC::Heap::didAllocate): (JSC::Heap::collectIfNecessaryOrDefer): * Source/JavaScriptCore/heap/Heap.h: (JSC::Heap::totalBytesAllocatedThisCycle): * Source/JavaScriptCore/heap/SpaceTimeMutatorScheduler.cpp: (JSC::SpaceTimeMutatorScheduler::beginCollection): (JSC::SpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl): * Source/JavaScriptCore/heap/StochasticSpaceTimeMutatorScheduler.cpp: (JSC::StochasticSpaceTimeMutatorScheduler::beginCollection): (JSC::StochasticSpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl): * Source/JavaScriptCore/runtime/VM.cpp: (JSC::VM::performOpportunisticallyScheduledTasks): * Source/WTF/wtf/PrintStream.h: (WTF::ConditionalDump::ConditionalDump): (WTF::ConditionalDump::dump const): * Source/WebCore/page/OpportunisticTaskScheduler.cpp: (WebCore::OpportunisticTaskScheduler::FullGCActivityCallback::doCollection): (WebCore::OpportunisticTaskScheduler::EdenGCActivityCallback::doCollection): Canonical link: https://commits.webkit.org/282325@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 4e1810: Remove unused/outdated run-layout-jsc script
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 4e1810f56bac8d9a1d8c1470a794ed61ec7f653a https://github.com/WebKit/WebKit/commit/4e1810f56bac8d9a1d8c1470a794ed61ec7f653a Author: Keith Miller Date: 2024-08-16 (Fri, 16 Aug 2024) Changed paths: R Tools/Scripts/run-layout-jsc Log Message: --- Remove unused/outdated run-layout-jsc script https://bugs.webkit.org/show_bug.cgi?id=277879 rdar://133560101 Reviewed by Mark Lam. As far as I know, no one uses this script. Let's get rid of it since using it doesn't seem to work anyway and it just confuses people. If someone wants to run the JSC CLIable LayoutTests they can just run `run-jsc-stress-tests LayoutTests/jsc-layout-tests.yaml`, which I believe works for all ports. * Tools/Scripts/run-layout-jsc: Removed. Canonical link: https://commits.webkit.org/282365@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 37a6ff: Add performance object with now to JSC CLI
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 37a6ff8b177984d11f4f6c82c3df4e898c7cfc4f https://github.com/WebKit/WebKit/commit/37a6ff8b177984d11f4f6c82c3df4e898c7cfc4f Author: Keith Miller Date: 2024-08-19 (Mon, 19 Aug 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Source/WTF/wtf/Seconds.h M Source/WebCore/page/Performance.cpp Log Message: --- Add performance object with now to JSC CLI https://bugs.webkit.org/show_bug.cgi?id=277811 rdar://133472694 Reviewed by Yijia Huang. We want this to be as close as possible to what WebCore does when using a high resolution timer (as we expect JetStream to do). This gives us more accurate numbers. One kinda weird thing is that the first time we call `performance.now()` in the CLI it will return 0 since we're also initializing our timeOrigin at that time. It's not even clear we need a timeOrigin since any benchmark is likely going to do `end - start` anyway so the timeOrigin would cancel out but maybe some FP rounding issues would show up that way. * Source/JavaScriptCore/jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): * Source/WTF/wtf/Seconds.h: * Source/WebCore/page/Performance.cpp: (WebCore::Performance::reduceTimeResolution): (WebCore::Performance::allowHighPrecisionTime): Canonical link: https://commits.webkit.org/282438@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 22b1c6: ASSERTION FAILED: isCell() WebKit/Source/JavaScrip...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 22b1c6974350230ff84219d2d05da6b88ebcf67a https://github.com/WebKit/WebKit/commit/22b1c6974350230ff84219d2d05da6b88ebcf67a Author: Keith Miller Date: 2024-08-19 (Mon, 19 Aug 2024) Changed paths: A JSTests/stress/runString-returns-globalThis-not-globalObject.js M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp Log Message: --- ASSERTION FAILED: isCell() WebKit/Source/JavaScriptCore/runtime/JSCJSValueInlines.h(598) : JSC::JSCell* JSC::JSValue::asCell() const https://bugs.webkit.org/show_bug.cgi?id=276934 rdar://132305364 Reviewed by Yusuke Suzuki. Some of our debugging functions currently return the globalObject directly. This is mostly ok because we expect to not fall over when the globalObject is directly exposed (rather than the globalThis proxy). That said, it seems when extending the GlobalObject it's possible to crash because we put_by_id_direct on the result of `ToThis`, which when is the GlobalObject (not the proxy) becomes jsUndefined(). To avoid spurious fuzzer crashes in the future this change has these functions return the globalThis. It seems none of the testing we did relies on the actual globalObject anyway and the globalThis is fine. * JSTests/stress/runString-returns-globalThis-not-globalObject.js: Added. (try.F): (try.C): * Source/JavaScriptCore/jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): * Source/JavaScriptCore/tools/JSDollarVM.cpp: Canonical link: https://commits.webkit.org/282453@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 67c8ea: [JSC] Atomics.and returns incorrect number type in...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 67c8ea6bd1f03982d2ad7d4a4a621cc81d954072 https://github.com/WebKit/WebKit/commit/67c8ea6bd1f03982d2ad7d4a4a621cc81d954072 Author: Keith Miller Date: 2024-08-19 (Mon, 19 Aug 2024) Changed paths: A JSTests/stress/atomics-ops-sign-extend-not-bit-mask.js M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp Log Message: --- [JSC] Atomics.and returns incorrect number type in JIT compiler https://bugs.webkit.org/show_bug.cgi?id=277895 rdar://134115829 Reviewed by Yusuke Suzuki. FTL was incorrectly masking signed non-canonical width Atomics operations rather than the unsigned operations. * JSTests/stress/atomics-ops-sign-extend-not-bit-mask.js: Added. (opt16): (optU16): (opt8): (optU8): * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): Canonical link: https://commits.webkit.org/282476@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] eed635: Object.keys(global) includes non-enumerable proper...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: eed6352f9b2365ff23dac63c6969040d14d72a68 https://github.com/WebKit/WebKit/commit/eed6352f9b2365ff23dac63c6969040d14d72a68 Author: Keith Miller Date: 2024-08-21 (Wed, 21 Aug 2024) Changed paths: A JSTests/stress/static-property-table-reconfigure-non-enumerable.js M Source/JavaScriptCore/runtime/JSObjectInlines.h Log Message: --- Object.keys(global) includes non-enumerable properties unless delete'd first https://bugs.webkit.org/show_bug.cgi?id=277899 rdar://134121649 Reviewed by Yusuke Suzuki. Right now when we reconfigure a static property we simply shadow it on the structure without reifying the static table. This works for normal property access but getNonReifiedStaticPropertyNames wasn't checking if the property had been shadowed. So it was still adding the static property to the list. With this change getNonReifiedStaticPropertyNames now checks if there's a shadowing property and skips it when necessary. I think there's still an issue with reconfigured properties being incorrectly ordered when reified e.g. ``` print(Object.keys(objectWithStaticProperties)); // bar,baz,foo makeNotEnum(objectWithStaticProperties, "foo"); delete objectWithStaticProperties.bar; print(Object.keys(objectWithStaticProperties)); // foo,baz ``` But it seems like reifying static properties reorders all names anyway so it's not clear how big of an issue this is. * JSTests/stress/static-property-table-reconfigure-non-enumerable.js: Added. * Source/JavaScriptCore/runtime/JSObjectInlines.h: (JSC::JSObject::getNonReifiedStaticPropertyNames): Canonical link: https://commits.webkit.org/282554@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] e5069d: Improve documentation of JSValueInWrappedObject
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: e5069d524cee591d58a906c913747a6610fcd93d https://github.com/WebKit/WebKit/commit/e5069d524cee591d58a906c913747a6610fcd93d Author: Keith Miller Date: 2024-08-28 (Wed, 28 Aug 2024) Changed paths: M Source/WebCore/bindings/js/JSValueInWrappedObject.h Log Message: --- Improve documentation of JSValueInWrappedObject https://bugs.webkit.org/show_bug.cgi?id=278793 rdar://134860417 Reviewed by Yijia Huang. Some folks have reported confusion about how to use this API, let's make it clear when to use set vs setWeakly. * Source/WebCore/bindings/js/JSValueInWrappedObject.h: Canonical link: https://commits.webkit.org/282850@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] e4715b: Unreviewed. Update OptionsGTK.cmake and NEWS for t...
Branch: refs/heads/webkitglib/2.44 Home: https://github.com/WebKit/WebKit Commit: e4715b88387c15a3ff8b7cc7a2efbde89c484710 https://github.com/WebKit/WebKit/commit/e4715b88387c15a3ff8b7cc7a2efbde89c484710 Author: Adrian Perez de Castro Date: 2024-09-08 (Sun, 08 Sep 2024) Changed paths: M Source/WebKit/gtk/NEWS M Source/cmake/OptionsGTK.cmake Log Message: --- Unreviewed. Update OptionsGTK.cmake and NEWS for the 2.44.4 release * Source/WebKit/gtk/NEWS: Add release notes. * Source/cmake/OptionsGTK.cmake: Bump version numbers. Canonical link: https://commits.webkit.org/274313.428@webkitglib/2.44 Commit: c5b1798337822c4bcced46b640e69ecae95cc350 https://github.com/WebKit/WebKit/commit/c5b1798337822c4bcced46b640e69ecae95cc350 Author: Keith Miller Date: 2024-09-09 (Mon, 09 Sep 2024) Changed paths: M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp M Source/JavaScriptCore/bytecode/UnlinkedMetadataTableInlines.h Log Message: --- Cherry-pick 279126@main (3a6e636fb3be). https://bugs.webkit.org/show_bug.cgi?id=274523 Fix linker error in JSC testing configuration https://bugs.webkit.org/show_bug.cgi?id=274523 rdar://128542072 Reviewed by Mark Lam. It seems like someone holding a Ref/RefPtr to UnlinkedMetadataTable didn't include the inlines header. Rather than figure out how to find the missing include I just moved the destructor to the .cpp file. I don't think the destructor is hot enough that inlining is needed. * Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp: (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): * Source/JavaScriptCore/bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): Deleted. Canonical link: https://commits.webkit.org/279126@main Canonical link: https://commits.webkit.org/274313.429@webkitglib/2.44 Compare: https://github.com/WebKit/WebKit/compare/fd73f137dcc6...c5b179833782 To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] d61272: WebAssembly.Table prototype functions need to do s...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: d612721aa438aac866eb2a46fd95bf866dc5bdb8 https://github.com/WebKit/WebKit/commit/d612721aa438aac866eb2a46fd95bf866dc5bdb8 Author: Keith Miller Date: 2024-09-10 (Tue, 10 Sep 2024) Changed paths: M JSTests/wasm/function-references/ref_types.js M JSTests/wasm/gc/arrays.js M JSTests/wasm/gc/i31.js M JSTests/wasm/gc/js-api.js M JSTests/wasm/gc/structs.js M JSTests/wasm/references/table_js_api.js A JSTests/wasm/regress/js-table-bad-set-type.js M JSTests/wasm/v8/js-api.js M Source/JavaScriptCore/wasm/WasmOperationsInlines.h M Source/JavaScriptCore/wasm/WasmTable.cpp M Source/JavaScriptCore/wasm/WasmTable.h M Source/JavaScriptCore/wasm/js/JSWebAssemblyHelpers.h M Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h M Source/JavaScriptCore/wasm/js/WebAssemblyExceptionConstructor.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyFunctionBase.h M Source/JavaScriptCore/wasm/js/WebAssemblyTablePrototype.cpp Log Message: --- WebAssembly.Table prototype functions need to do subtype checks https://bugs.webkit.org/show_bug.cgi?id=279444 rdar://134785807 Reviewed by Yusuke Suzuki. Table.prototype.set/grow don't check that the value they are inserting into the table is actually a subtype of the funcref table's actual type. This patch fixes that. I also moved some of the verification logic into the table itself rather than in the prototype function. This seems like a better abstraction since the checks are now done by the table instead of any caller. Also, convert a bunch of the RELEASE_ASSERTs into ASSERTs since they're unlikely be hit in practice at this point and some of them e.g. isSubtype, could be reasonably expensive to do at runtime. * JSTests/wasm/function-references/ref_types.js: (async testRefTypesInTables): * JSTests/wasm/gc/arrays.js: * JSTests/wasm/gc/i31.js: (testI31Table): * JSTests/wasm/gc/js-api.js: * JSTests/wasm/gc/structs.js: * JSTests/wasm/references/table_js_api.js: (async testTableGrowForFuncrefTables): (async testTableSetForFuncrefTables): * JSTests/wasm/regress/js-table-bad-set-type.js: Added. (async test): * JSTests/wasm/v8/js-api.js: * Source/JavaScriptCore/wasm/WasmOperationsInlines.h: (JSC::Wasm::tableSet): * Source/JavaScriptCore/wasm/WasmTable.cpp: (JSC::Wasm::Table::copy): (JSC::Wasm::Table::clear): (JSC::Wasm::Table::set): (JSC::Wasm::Table::get const): (JSC::Wasm::FuncRefTable::setFunction): (JSC::Wasm::FuncRefTable::copyFunction): (JSC::Wasm::FuncRefTable::clear): (JSC::Wasm::FuncRefTable::set): * Source/JavaScriptCore/wasm/WasmTable.h: * Source/JavaScriptCore/wasm/js/JSWebAssemblyHelpers.h: (JSC::toWebAssemblyValue): (JSC::fromJSValue): Deleted. * Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::grow): (JSC::JSWebAssemblyTable::get): (JSC::JSWebAssemblyTable::set): (JSC::JSWebAssemblyTable::clear): * Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h: * Source/JavaScriptCore/wasm/js/WebAssemblyExceptionConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * Source/JavaScriptCore/wasm/js/WebAssemblyFunctionBase.h: (JSC::WebAssemblyFunctionBase::type const): * Source/JavaScriptCore/wasm/js/WebAssemblyTablePrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): Canonical link: https://commits.webkit.org/283434@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] d8cbb6: Share JS -> Wasm IC entrypoint code
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: d8cbb604f912d93e8d282803766de3578aea5852 https://github.com/WebKit/WebKit/commit/d8cbb604f912d93e8d282803766de3578aea5852 Author: Keith Miller Date: 2024-09-11 (Wed, 11 Sep 2024) Changed paths: M JSTests/stress/ftl-put-by-id-setter-exception-interesting-live-state.js M JSTests/wasm/WASM.js M JSTests/wasm/wabt-wrapper.js M Source/JavaScriptCore/bytecode/Repatch.cpp M Source/JavaScriptCore/interpreter/CallFrame.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.h M Source/JavaScriptCore/jit/CCallHelpers.h M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/runtime/SamplingProfiler.cpp M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmCallee.h M Source/JavaScriptCore/wasm/WasmCallingConvention.h M Source/JavaScriptCore/wasm/WasmCompilationMode.cpp M Source/JavaScriptCore/wasm/WasmCompilationMode.h M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmOperations.h M Source/JavaScriptCore/wasm/WasmSectionParser.cpp M Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp M Source/JavaScriptCore/wasm/WasmTypeDefinition.h M Source/JavaScriptCore/wasm/js/JSToWasm.cpp M Source/JavaScriptCore/wasm/js/JSToWasm.h M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.h M Source/JavaScriptCore/wasm/js/WebAssemblyFunctionBase.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyFunctionBase.h M Tools/Scripts/run-jsc-stress-tests Log Message: --- Share JS -> Wasm IC entrypoint code https://bugs.webkit.org/show_bug.cgi?id=278674 rdar://134724248 Reviewed by Yusuke Suzuki. Right now JS -> Wasm IC code is specific to a WebAssemblyFunction but most of the logic is shared between every function with the same Wasm::Signature. This patch now shares the JIT code between every WebAssemblyFunction with the same signature. To make this work we now get the instance/entrypoint from the WebAssemblyFunction via a load rather than embedding the constants/address of constants into the function. Most of the other logic is the same however, in order to not load the instance twice we can no longer use wasmContextInstancePointer as a scratch. Now, for arm64 we just use wasmBaseMemoryPointer as the scratch and for x86 we try to use argumentGPR0 when not initializing the first GP argument otherwise we clobber numberTagRegister. We could end up using numberTagRegister again if there's a FP argument before the first GP argument e.g. `(f32, i64) -> void` * JSTests/wasm/WASM.js: * JSTests/wasm/wabt-wrapper.js: (export.async compile): * Source/JavaScriptCore/bytecode/Repatch.cpp: (JSC::jsToWasmICCodePtr): * Source/JavaScriptCore/interpreter/CallFrame.cpp: (JSC::CallFrame::dump const): * Source/JavaScriptCore/jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitLoadStructure): * Source/JavaScriptCore/jit/AssemblyHelpers.h: * Source/JavaScriptCore/jit/CCallHelpers.h: (JSC::CCallHelpers::operationExceptionRegister): * Source/JavaScriptCore/jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): * Source/JavaScriptCore/runtime/SamplingProfiler.cpp: (JSC::descriptionForLocation): * Source/JavaScriptCore/wasm/WasmCallee.h: * Source/JavaScriptCore/wasm/WasmCallingConvention.h: (JSC::Wasm::JSCallingConvention::callInformationFor const): * Source/JavaScriptCore/wasm/WasmCompilationMode.cpp: (JSC::Wasm::makeString): Deleted. * Source/JavaScriptCore/wasm/WasmCompilationMode.h: * Source/JavaScriptCore/wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/wasm/WasmOperations.h: * Source/JavaScriptCore/wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseException): * Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp: (JSC::Wasm::FunctionSignature::FunctionSignature): (JSC::Wasm::FunctionSignature::~FunctionSignature): * Source/JavaScriptCore/wasm/WasmTypeDefinition.h: (JSC::Wasm::TypeDefinition::TypeDefinition): (JSC::Wasm::FunctionSignature::FunctionSignature): Deleted. * Source/JavaScriptCore/wasm/js/JSToWasm.cpp: (JSC::Wasm::marshallJSResult): (JSC::Wasm::createJSToWasmJITInterpreter): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::trampolineReservedStackSize): (JSC::Wasm::FunctionSignature::jsToWasmICEntrypoint const): * Source/JavaScriptCore/wasm/js/JSToWasm.h: * Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::usedCalleeSaveRegisters): (JSC::WebAssemblyFunction::WebAssemblyFunction): (JSC::WebAssemblyFunction::usesTagRegisters const): Deleted. (JSC::WebAssemblyFunction::calleeSaves const): Deleted. (JSC::WebAssemblyFunction::usedCalleeSaveRegisters const): Deleted. (JSC::trampolineReservedStackSize): Deleted. (JSC::WebAssemblyFunction::jsCallEntrypoint
[webkit-changes] [WebKit/WebKit] a92244: Add logging when mach exception thread adoption fails
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: a9224418c5c1db524ee316d0c5405723f1355326 https://github.com/WebKit/WebKit/commit/a9224418c5c1db524ee316d0c5405723f1355326 Author: Keith Miller Date: 2024-04-10 (Wed, 10 Apr 2024) Changed paths: M Source/WTF/wtf/Assertions.h M Source/WTF/wtf/threads/Signals.cpp Log Message: --- Add logging when mach exception thread adoption fails https://bugs.webkit.org/show_bug.cgi?id=272494 rdar://126089415 Reviewed by Justin Michaud. We're seeing crashes from these asserts but it's not clear what the state is at that time. Adding some extra logging. * Source/WTF/wtf/Assertions.h: (wtfCrashArg): * Source/WTF/wtf/threads/Signals.cpp: (WTF::setExceptionPorts): (WTF::registerThreadForMachExceptionHandling): Canonical link: https://commits.webkit.org/277333@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] fd80b6: OSR Exit disassembly dump should convert ASCIILite...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: fd80b6547c5d44dbf20108f5d34e584bf7230fc0 https://github.com/WebKit/WebKit/commit/fd80b6547c5d44dbf20108f5d34e584bf7230fc0 Author: Keith Miller Date: 2024-04-16 (Tue, 16 Apr 2024) Changed paths: M Source/JavaScriptCore/dfg/DFGOSRExit.cpp M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp Log Message: --- OSR Exit disassembly dump should convert ASCIILiteral to char* https://bugs.webkit.org/show_bug.cgi?id=272760 rdar://126560240 Reviewed by Yusuke Suzuki. When we made ASCIILiteral a wrapper around std::span I missed there we some places that were passing the ASCIILiteral to a format string relying on them having the same layout. Instead we should just pass the characters explicitly. * Source/JavaScriptCore/dfg/DFGOSRExit.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): Canonical link: https://commits.webkit.org/277549@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ba07b6: Cleanup hardened mach exceptions and formalize fal...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: ba07b609dde3d292264be5576a7daa415475eaf2 https://github.com/WebKit/WebKit/commit/ba07b609dde3d292264be5576a7daa415475eaf2 Author: Keith Miller Date: 2024-04-17 (Wed, 17 Apr 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/runtime/InitializeThreading.cpp M Source/JavaScriptCore/runtime/JSCConfig.cpp M Source/JavaScriptCore/runtime/JSCConfig.h M Source/JavaScriptCore/runtime/VM.cpp M Source/JavaScriptCore/runtime/VMEntryScope.cpp M Source/JavaScriptCore/runtime/VMTraps.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h M Source/WTF/wtf/PlatformRegisters.cpp M Source/WTF/wtf/Threading.cpp M Source/WTF/wtf/WTFConfig.cpp M Source/WTF/wtf/WTFConfig.h M Source/WTF/wtf/threads/Signals.cpp M Source/WTF/wtf/threads/Signals.h M Source/WTF/wtf/win/SignalsWin.cpp M Source/WebKit/GPUProcess/EntryPoint/Cocoa/XPCService/GPUServiceEntryPoint.mm M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in M Tools/DumpRenderTree/mac/DumpRenderTree.mm M Tools/TestWebKitAPI/Tests/WTF/Signals.cpp Log Message: --- Cleanup hardened mach exceptions and formalize fallback https://bugs.webkit.org/show_bug.cgi?id=272839 rdar://126634499 Reviewed by Yusuke Suzuki. This change does a couple of things: 1) Refactor the signal handler API after https://commits.webkit.org/276579@main which had mach exception users pass the mask of exceptions they would ever want to handle at initialization time (before they register their handler). Instead the new signal handler API registers our handlers with the kernel at finalization time. At which point we have a list of every exception handler added. 2) Remove the finalizeSignalHandlers function and finalize signal handlers when WTF::Config finalizes. 3) Remove disableSignalHandling function as it never really worked (signals could still get registered before we called disable) and we mostly rely on the sandbox to block signals in lockdown mode. 3) Rename SignalHandlers::InitState entries to better reflect the new design and use it for all configurations not just mach ports. 4) Formalized the fallback added in https://commits.webkit.org/276579@main we need it for JSC API users that don't have the hardened API in their sandbox. 5) Remove `isX86BinaryRunningOnARM()` check since that didn't seem to work anyway. We'll probably have to remove signal handling under Rosetta as I couldn't get it to work. 6) Save the secret key for our hardened handler in Signals.cpp before finalization and only let API users see it via presignReturnPCForHandler so they can't accidentally save it somewhere an attacker could see later. We also carefully zero it at finalization time after passing it to the kernel via `task_register_hardened_exception_handler`. 7) Move disabledFreezingForTesting to WTF::Config since that's the config that actually does the freezing not JSC::Config. This allows WTF::Config to control finalizing signal handlers. 8) Remove some cases from com.apple.WebKit.WebContent.sb.in to simplify the profile slightly. We don't need to guard the `(require-not (webcontent-process-launched))` check on `ENABLE(BLOCK_SET_EXCEPTION_PORTS)` because we have `webcontent-process-launched` anywhere we `HAVE(HARDENED_MACH_EXCEPTIONS)` anyway. * Source/JavaScriptCore/jsc.cpp: (main): (CommandLine::parseArguments): * Source/JavaScriptCore/runtime/InitializeThreading.cpp: (JSC::initialize): * Source/JavaScriptCore/runtime/JSCConfig.cpp: (JSC::Config::disableFreezingForTesting): Deleted. * Source/JavaScriptCore/runtime/JSCConfig.h: (JSC::Config::disableFreezingForTesting): (JSC::Config::finalize): (JSC::Config::permanentlyFreeze): Deleted. * Source/JavaScriptCore/runtime/VM.cpp: (JSC::VM::VM): * Source/JavaScriptCore/runtime/VMEntryScope.cpp: (JSC::VMEntryScope::setUpSlow): * Source/JavaScriptCore/runtime/VMTraps.cpp: * Source/JavaScriptCore/tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES): * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::activateSignalingMemory): (JSC::Wasm::prepareSignalingMemory): (JSC::Wasm::MachExceptionSigningKey::MachExceptionSigningKey): Deleted. * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h: * Source/WTF/wtf/PlatformRegisters.cpp: (WTF::threadStatePCInternal): * Source/WTF/wtf/Threading.cpp: (WTF::initialize): * Source/WTF/wtf/WTFConfig.cpp: (WTF::Config::initialize): (WTF::Config::finalize): (WTF::Config::permanentlyFreeze): (WTF::Config::disableFreezingForTesting): * Source/WTF/wtf/WTFConfig.h: * Source/WTF/wtf/threads/Signals.cpp: (WTF::SignalHandlers::add): (WTF::SignalHandler
[webkit-changes] [WebKit/WebKit] 915599: Hardened Mach exception signing key can't be zero
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 9155990f356664ef6263fb7796ad4e09aa46aeff https://github.com/WebKit/WebKit/commit/9155990f356664ef6263fb7796ad4e09aa46aeff Author: Keith Miller Date: 2024-04-20 (Sat, 20 Apr 2024) Changed paths: M Source/WTF/wtf/CryptographicallyRandomNumber.cpp M Source/WTF/wtf/CryptographicallyRandomNumber.h M Source/WTF/wtf/threads/Signals.cpp Log Message: --- Hardened Mach exception signing key can't be zero https://bugs.webkit.org/show_bug.cgi?id=273003 rdar://125605825 Reviewed by Yusuke Suzuki. This patch fixes a bug where the ARM64E ABI doesn't allow the pointer (1st) argument of `ptrauth_blend_discriminator` to be zero. It also adds a new overload of `cryptographicallyRandomNumber` for `uint8_t`, since there's no point in wasting bits while trying to get a non-zero key. * Source/WTF/wtf/CryptographicallyRandomNumber.cpp: (WTF::cryptographicallyRandomNumber): (WTF::cryptographicallyRandomNumber): (WTF::cryptographicallyRandomNumber): * Source/WTF/wtf/CryptographicallyRandomNumber.h: * Source/WTF/wtf/threads/Signals.cpp: (WTF::SignalHandlers::initialize): Canonical link: https://commits.webkit.org/28@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 34d7f5: Fix JSCOnly Mac build
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 34d7f551c40ab7253255304e1443394d5e49 https://github.com/WebKit/WebKit/commit/34d7f551c40ab7253255304e1443394d5e49 Author: Keith Miller Date: 2024-04-23 (Tue, 23 Apr 2024) Changed paths: M Source/WTF/wtf/PlatformUse.h Log Message: --- Fix JSCOnly Mac build https://bugs.webkit.org/show_bug.cgi?id=273078 rdar://126873329 Reviewed by Yusuke Suzuki. We need to use the pthreads JIT permissions API on Apple platforms (other than iOS family devices in OpenSource). * Source/WTF/wtf/PlatformUse.h: Canonical link: https://commits.webkit.org/277861@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 5ca7d6: REGRESSION(277648@main) Breaks prewarmed safari pr...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 5ca7d6c795619fb7baf3d28ecaffcef5e6b69f69 https://github.com/WebKit/WebKit/commit/5ca7d6c795619fb7baf3d28ecaffcef5e6b69f69 Author: Keith Miller Date: 2024-04-23 (Tue, 23 Apr 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/runtime/InitializeThreading.cpp M Source/JavaScriptCore/runtime/JSCConfig.cpp M Source/JavaScriptCore/runtime/JSCConfig.h M Source/JavaScriptCore/runtime/VM.cpp M Source/JavaScriptCore/runtime/VMEntryScope.cpp M Source/JavaScriptCore/runtime/VMTraps.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h M Source/WTF/wtf/CryptographicallyRandomNumber.cpp M Source/WTF/wtf/CryptographicallyRandomNumber.h M Source/WTF/wtf/PlatformRegisters.cpp M Source/WTF/wtf/Threading.cpp M Source/WTF/wtf/WTFConfig.cpp M Source/WTF/wtf/WTFConfig.h M Source/WTF/wtf/threads/Signals.cpp M Source/WTF/wtf/threads/Signals.h M Source/WTF/wtf/win/SignalsWin.cpp M Source/WebKit/GPUProcess/EntryPoint/Cocoa/XPCService/GPUServiceEntryPoint.mm M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in M Tools/DumpRenderTree/mac/DumpRenderTree.mm M Tools/TestWebKitAPI/Tests/WTF/Signals.cpp Log Message: --- REGRESSION(277648@main) Breaks prewarmed safari processes https://bugs.webkit.org/show_bug.cgi?id=273157 rdar://126767343 Unreviewed, revert. * Source/JavaScriptCore/jsc.cpp: (main): (CommandLine::parseArguments): * Source/JavaScriptCore/runtime/InitializeThreading.cpp: (JSC::initialize): * Source/JavaScriptCore/runtime/JSCConfig.cpp: (JSC::Config::disableFreezingForTesting): * Source/JavaScriptCore/runtime/JSCConfig.h: (JSC::Config::permanentlyFreeze): (JSC::Config::disableFreezingForTesting): Deleted. (JSC::Config::finalize): Deleted. * Source/JavaScriptCore/runtime/VM.cpp: (JSC::VM::VM): * Source/JavaScriptCore/runtime/VMEntryScope.cpp: (JSC::VMEntryScope::setUpSlow): * Source/JavaScriptCore/runtime/VMTraps.cpp: * Source/JavaScriptCore/tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES): * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::MachExceptionSigningKey::MachExceptionSigningKey): (JSC::Wasm::trapHandler): (JSC::Wasm::activateSignalingMemory): (JSC::Wasm::prepareSignalingMemory): (): Deleted. * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h: * Source/WTF/wtf/CryptographicallyRandomNumber.cpp: (WTF::cryptographicallyRandomNumber): (WTF::cryptographicallyRandomNumber): (WTF::cryptographicallyRandomNumber): Deleted. * Source/WTF/wtf/CryptographicallyRandomNumber.h: * Source/WTF/wtf/PlatformRegisters.cpp: (WTF::threadStatePCInternal): * Source/WTF/wtf/Threading.cpp: (WTF::initialize): * Source/WTF/wtf/WTFConfig.cpp: (WTF::Config::initialize): (WTF::Config::permanentlyFreeze): (WTF::Config::finalize): Deleted. (WTF::Config::disableFreezingForTesting): Deleted. * Source/WTF/wtf/WTFConfig.h: * Source/WTF/wtf/threads/Signals.cpp: (WTF::SignalHandlers::add): (WTF::initMachExceptionHandlerThread): (WTF::setExceptionPorts): (WTF::activeThreads): (WTF::registerThreadForMachExceptionHandling): (WTF::addSignalHandler): (WTF::activateSignalHandlersFor): (WTF::finalizeSignalHandlers): (WTF::jscSignalHandler): (WTF::SignalHandlers::initialize): (WTF::SignalHandlers::presignReturnPCForHandler): Deleted. (WTF::toMachMask): Deleted. (WTF::SignalHandlers::finalize): Deleted. * Source/WTF/wtf/threads/Signals.h: (WTF::toMachMask): (WTF::initializeSignalHandling): (WTF::disableSignalHandling): * Source/WTF/wtf/win/SignalsWin.cpp: (WTF::SignalHandlers::add): (WTF::addSignalHandler): (WTF::activateSignalHandlersFor): (WTF::SignalHandlers::initialize): (WTF::finalizeSignalHandlers): (WTF::SignalHandlers::finalize): Deleted. * Source/WebKit/GPUProcess/EntryPoint/Cocoa/XPCService/GPUServiceEntryPoint.mm: (GPU_SERVICE_INITIALIZER): * Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in: * Tools/DumpRenderTree/mac/DumpRenderTree.mm: (testOptionsForTest): * Tools/TestWebKitAPI/Tests/WTF/Signals.cpp: (TEST(Signals, SignalsWorkOnExit)): (TEST(Signals, SignalsAccessFault)): Canonical link: https://commits.webkit.org/277906@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 7a6fd5: Cleanup hardened mach exceptions and formalize fal...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 7a6fd55b43d76cbfeacf8a55c39005c081bd03f2 https://github.com/WebKit/WebKit/commit/7a6fd55b43d76cbfeacf8a55c39005c081bd03f2 Author: Keith Miller Date: 2024-04-25 (Thu, 25 Apr 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/runtime/InitializeThreading.cpp M Source/JavaScriptCore/runtime/JSCConfig.cpp M Source/JavaScriptCore/runtime/JSCConfig.h M Source/JavaScriptCore/runtime/VM.cpp M Source/JavaScriptCore/runtime/VMEntryScope.cpp M Source/JavaScriptCore/runtime/VMTraps.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp M Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h M Source/WTF/wtf/CryptographicallyRandomNumber.cpp M Source/WTF/wtf/CryptographicallyRandomNumber.h M Source/WTF/wtf/PlatformRegisters.cpp M Source/WTF/wtf/Threading.cpp M Source/WTF/wtf/WTFConfig.cpp M Source/WTF/wtf/WTFConfig.h M Source/WTF/wtf/threads/Signals.cpp M Source/WTF/wtf/threads/Signals.h M Source/WTF/wtf/win/SignalsWin.cpp M Source/WebKit/GPUProcess/EntryPoint/Cocoa/XPCService/GPUServiceEntryPoint.mm M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in M Tools/DumpRenderTree/mac/DumpRenderTree.mm M Tools/TestWebKitAPI/Tests/WTF/Signals.cpp Log Message: --- Cleanup hardened mach exceptions and formalize fallback https://bugs.webkit.org/show_bug.cgi?id=272839 rdar://126634499 Reviewed by Yusuke Suzuki. This version adds a check in registerThreadForMachExceptionHandling that we're actually using mach exceptions and have some registered. Not checking mostly worked, as the OS would happly accept garbage parameters, except when our sandbox blocked `thread_set_exception_ports` in the WebContentProcess. In that case we would trip our ASSERT and crash. * Source/JavaScriptCore/jsc.cpp: (main): (CommandLine::parseArguments): * Source/JavaScriptCore/runtime/InitializeThreading.cpp: (JSC::initialize): * Source/JavaScriptCore/runtime/JSCConfig.cpp: (JSC::Config::disableFreezingForTesting): Deleted. * Source/JavaScriptCore/runtime/JSCConfig.h: (JSC::Config::disableFreezingForTesting): (JSC::Config::finalize): (JSC::Config::permanentlyFreeze): Deleted. * Source/JavaScriptCore/runtime/VM.cpp: (JSC::VM::VM): * Source/JavaScriptCore/runtime/VMEntryScope.cpp: (JSC::VMEntryScope::setUpSlow): * Source/JavaScriptCore/runtime/VMTraps.cpp: * Source/JavaScriptCore/tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES): * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::activateSignalingMemory): (JSC::Wasm::prepareSignalingMemory): (JSC::Wasm::MachExceptionSigningKey::MachExceptionSigningKey): Deleted. * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h: * Source/WTF/wtf/CryptographicallyRandomNumber.cpp: (WTF::cryptographicallyRandomNumber): (WTF::cryptographicallyRandomNumber): (WTF::cryptographicallyRandomNumber): * Source/WTF/wtf/CryptographicallyRandomNumber.h: * Source/WTF/wtf/PlatformRegisters.cpp: (WTF::threadStatePCInternal): * Source/WTF/wtf/Threading.cpp: (WTF::initialize): * Source/WTF/wtf/WTFConfig.cpp: (WTF::Config::initialize): (WTF::Config::finalize): (WTF::Config::permanentlyFreeze): (WTF::Config::disableFreezingForTesting): * Source/WTF/wtf/WTFConfig.h: * Source/WTF/wtf/threads/Signals.cpp: (WTF::SignalHandlers::add): (WTF::SignalHandlers::presignReturnPCForHandler): (WTF::initMachExceptionHandlerThread): (WTF::toMachMask): (WTF::setExceptionPorts): (WTF::activeThreads): (WTF::registerThreadForMachExceptionHandling): (WTF::activateSignalHandlersFor): (WTF::addSignalHandler): (WTF::jscSignalHandler): (WTF::SignalHandlers::initialize): (WTF::SignalHandlers::finalize): (WTF::finalizeSignalHandlers): Deleted. * Source/WTF/wtf/threads/Signals.h: (WTF::toMachMask): Deleted. (WTF::initializeSignalHandling): Deleted. (WTF::disableSignalHandling): Deleted. * Source/WTF/wtf/win/SignalsWin.cpp: (WTF::SignalHandlers::add): (WTF::addSignalHandler): (WTF::activateSignalHandlersFor): (WTF::SignalHandlers::initialize): (WTF::SignalHandlers::finalize): (WTF::finalizeSignalHandlers): Deleted. * Source/WebKit/GPUProcess/EntryPoint/Cocoa/XPCService/GPUServiceEntryPoint.mm: (GPU_SERVICE_INITIALIZER): * Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb.in: * Tools/DumpRenderTree/mac/DumpRenderTree.mm: (testOptionsForTest): * Tools/TestWebKitAPI/Tests/WTF/Signals.cpp: (TEST(Signals, SignalsWorkOnExit)): (TEST(Signals, SignalsAccessFault)): Canonical link: https://commits.webkit.org/277994@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webki
[webkit-changes] [WebKit/WebKit] ec5f9f: Improve error message when we can't find Internal ...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: ec5f9ff74cdb82bfaf65673ac04dc17babe7f440 https://github.com/WebKit/WebKit/commit/ec5f9ff74cdb82bfaf65673ac04dc17babe7f440 Author: Keith Miller Date: 2024-04-25 (Thu, 25 Apr 2024) Changed paths: M Tools/Scripts/webkitdirs.pm Log Message: --- Improve error message when we can't find Internal xcworkspace. https://bugs.webkit.org/show_bug.cgi?id=273253 rdar://127058846 Reviewed by Elliott Williams. I guess `Cwd::realpath` checks the path actually exists and returns undef if it doesn't. So if the internal workspace didn't exist then our error message would try to concatenate undef and error. I think we technically no longer need the `-e $configuredXcodeWorkspace` but I figure its better to be safe if different versions of perl have different behavior. * Tools/Scripts/webkitdirs.pm: (determineConfiguredXcodeWorkspaceOrDefault): Canonical link: https://commits.webkit.org/277996@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] a6341c: Makefile.shared should pass SDKROOT to set-webkit-...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: a6341cabd933197f63da3b9adcafed6dab5dd9e3 https://github.com/WebKit/WebKit/commit/a6341cabd933197f63da3b9adcafed6dab5dd9e3 Author: Keith Miller Date: 2024-04-26 (Fri, 26 Apr 2024) Changed paths: M Makefile.shared Log Message: --- Makefile.shared should pass SDKROOT to set-webkit-configuration https://bugs.webkit.org/show_bug.cgi?id=273320 rdar://127114398 Reviewed by David Kilzer. This fixes the build scenario when Apple WebKittens try to do the OS build with `make debug SDKROOT=macosx`. Previously we wouldn't forward the `SDKROOT` to `set-webkit-configuration` which assumed the user wanted to use the .internal SDK. This meant `set-webkit-configuration` would complain because it couldn't find the Internal directory. * Makefile.shared: Canonical link: https://commits.webkit.org/278043@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 506d7f: build-jsc should have a --rosetta option
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 506d7f9b1b39eea4d58b6ba9befeda94877e1d8d https://github.com/WebKit/WebKit/commit/506d7f9b1b39eea4d58b6ba9befeda94877e1d8d Author: Keith Miller Date: 2024-04-26 (Fri, 26 Apr 2024) Changed paths: M Source/JavaScriptCore/Scripts/process-entitlements.sh M Source/WTF/wtf/PlatformHave.h M Tools/Scripts/webkitperl/BuildSubproject.pm Log Message: --- build-jsc should have a --rosetta option https://bugs.webkit.org/show_bug.cgi?id=273338 rdar://127131119 Reviewed by Yusuke Suzuki. Right now if you try to run an x86_64 build of JSC under rosetta it won't have JIT. This is because Rosetta doesn't play nice with some of the security entitlements we use. Additionally, for historical perfomance reasons we disabled JIT when in a translated process. This patch adds a new option to build-jsc (--rosetta). The --rosetta option sets a flag in `process-entitlements.sh` to stop adding the bad entitlements for `jsc` and other JSC test binaries. The --rosetta option also sets `HAVE_CPU_TRANSLATION_CAPABILITY=0` making JSC think it's actually running natively. Also, pass --makeArgs as `GCC_PREPROCESSOR_ADDITONS` in `build-jsc` when building with xcodebuild. Lastly, do a little code cleanup in buildUpToProject as well. * Source/JavaScriptCore/Scripts/process-entitlements.sh: * Source/WTF/wtf/PlatformHave.h: * Tools/Scripts/webkitperl/BuildSubproject.pm: (buildUpToProject): Canonical link: https://commits.webkit.org/278059@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] f8e2f4: ToPropertyKeyOrNumber incorrectly says it doesn't ...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: f8e2f45c2312e66f34db314a2ca054d0adaac66e https://github.com/WebKit/WebKit/commit/f8e2f45c2312e66f34db314a2ca054d0adaac66e Author: Keith Miller Date: 2024-04-29 (Mon, 29 Apr 2024) Changed paths: A JSTests/stress/ToPropertyKeyOrNumber-AI-should-include-number.js M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp Log Message: --- ToPropertyKeyOrNumber incorrectly says it doesn't return a number in AI https://bugs.webkit.org/show_bug.cgi?id=273429 rdar://127225001 Reviewed by Yusuke Suzuki. Right now ToPropertyKeyOrNumber falls through to ToPropertyKey, which says it always returns `SpecString | SpecSymbol`. This is obviously wrong. * JSTests/stress/ToPropertyKeyOrNumber-AI-should-include-number.js: Added. (opt.f): (opt): * Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp: Canonical link: https://commits.webkit.org/278136@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 0de4d5: JSC cli should have a short option for useConcurre...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 0de4d5991ad42c9ab64d474d391978429e842e51 https://github.com/WebKit/WebKit/commit/0de4d5991ad42c9ab64d474d391978429e842e51 Author: Keith Miller Date: 2024-05-01 (Wed, 01 May 2024) Changed paths: M Source/JavaScriptCore/jsc.cpp M Tools/Scripts/run-jsc-stress-tests Log Message: --- JSC cli should have a short option for useConcurrentJIT=0 https://bugs.webkit.org/show_bug.cgi?id=273528 rdar://127327863 Reviewed by Yusuke Suzuki. This is a commonly used option so it should have a short option. This patch makes the option `-s` for "synchronous compilation". Currently, this is used for signal handling but that's only used by the test harness so we can move that to a long option, `--signal-expected`. * Source/JavaScriptCore/jsc.cpp: (printUsageStatement): (CommandLine::parseArguments): * Tools/Scripts/run-jsc-stress-tests: Canonical link: https://commits.webkit.org/278231@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] a64941: Add a hasTraps() check in B3::Value::effects()
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: a649419b8cf4bc2d1b95dfc5c2ba17bf4310de8c https://github.com/WebKit/WebKit/commit/a649419b8cf4bc2d1b95dfc5c2ba17bf4310de8c Author: Keith Miller Date: 2024-05-03 (Fri, 03 May 2024) Changed paths: M Source/JavaScriptCore/b3/B3EliminateDeadCode.cpp M Source/JavaScriptCore/b3/B3Value.cpp Log Message: --- Add a hasTraps() check in B3::Value::effects() https://bugs.webkit.org/show_bug.cgi?id=273648 rdar://127458113 Reviewed by Yusuke Suzuki. Some profiling of reduceStrength showed we spent a number of samples in B3::Value::effects() checking traps(). But most B3 Kinds don't ever have traps(). Since we just switched on the Kind we can use `hasTraps()` hoist the traps() check into the cases that actually use it. * Source/JavaScriptCore/b3/B3EliminateDeadCode.cpp: (JSC::B3::eliminateDeadCodeImpl): * Source/JavaScriptCore/b3/B3Value.cpp: (JSC::B3::Value::effects const): Canonical link: https://commits.webkit.org/278338@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] fc1560: JIT operations should return the current exception...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: fc1560bbe0bacc088faf2b65876379f39a324979 https://github.com/WebKit/WebKit/commit/fc1560bbe0bacc088faf2b65876379f39a324979 Author: Keith Miller Date: 2024-05-03 (Fri, 03 May 2024) Changed paths: M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/assembler/MacroAssembler.h M Source/JavaScriptCore/assembler/MacroAssemblerARM64.cpp M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.cpp M Source/JavaScriptCore/assembler/MacroAssemblerRISCV64.cpp M Source/JavaScriptCore/assembler/MacroAssemblerX86Common.cpp M Source/JavaScriptCore/b3/B3Type.h M Source/JavaScriptCore/b3/B3Validate.cpp M Source/JavaScriptCore/b3/air/AirCCallingConvention.cpp M Source/JavaScriptCore/b3/testb3.h M Source/JavaScriptCore/b3/testb3_5.cpp M Source/JavaScriptCore/b3/testb3_6.cpp M Source/JavaScriptCore/b3/testb3_7.cpp M Source/JavaScriptCore/dfg/DFGAbstractInterpreter.h M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h M Source/JavaScriptCore/dfg/DFGArithMode.h M Source/JavaScriptCore/dfg/DFGArrayifySlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp M Source/JavaScriptCore/dfg/DFGCallArrayAllocatorSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGJITCompiler.h M Source/JavaScriptCore/dfg/DFGOSRExit.cpp M Source/JavaScriptCore/dfg/DFGOSRExit.h M Source/JavaScriptCore/dfg/DFGOperations.cpp M Source/JavaScriptCore/dfg/DFGOperations.h M Source/JavaScriptCore/dfg/DFGSaneStringGetByValSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.h M Source/JavaScriptCore/ftl/FTLOperations.cpp M Source/JavaScriptCore/ftl/FTLOperations.h M Source/JavaScriptCore/ftl/FTLOutput.cpp M Source/JavaScriptCore/ftl/FTLOutput.h M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.h M Source/JavaScriptCore/jit/CCallHelpers.h M Source/JavaScriptCore/jit/JIT.h M Source/JavaScriptCore/jit/JITCall.cpp M Source/JavaScriptCore/jit/JITInlines.h M Source/JavaScriptCore/jit/JITOperations.cpp M Source/JavaScriptCore/jit/JITOperations.h A Source/JavaScriptCore/jit/OperationResult.h M Source/JavaScriptCore/llint/LLIntThunks.h M Source/JavaScriptCore/runtime/AtomicsObject.cpp M Source/JavaScriptCore/runtime/CommonSlowPaths.h M Source/JavaScriptCore/runtime/ExceptionScope.h M Source/JavaScriptCore/runtime/HashMapImplInlines.h M Source/JavaScriptCore/runtime/MathCommon.cpp M Source/JavaScriptCore/runtime/MathCommon.h M Source/JavaScriptCore/runtime/StringPrototype.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmOperations.h M Source/JavaScriptCore/yarr/YarrJIT.cpp M Source/WTF/wtf/PlatformCallingConventions.h M Source/WTF/wtf/Threading.cpp M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm M Source/WebCore/bindings/scripts/test/JS/JSTestDOMJIT.cpp M Source/WebCore/cssjit/SelectorCompiler.cpp M Source/WebCore/domjit/JSDocumentDOMJIT.cpp Log Message: --- JIT operations should return the current exception in a return GPR when it's free. https://bugs.webkit.org/show_bug.cgi?id=273264 rdar://127065985 Reviewed by Yusuke Suzuki. This patch makes a lot of changes so that we can pass the current exception in a return register. 1) There's now a new set of macros for JIT_OPERATIONS that wrap the return type in a templated struct containing the true result and a pointer to the current exception if there's an extra return register in the C++ calling convention (and returning a `struct` won't push everything to the stack... armv7...). 2) Exception checking macro assembler functions take an optional register parameter, which is the register the exception is in, typically returnGPR2 but sometimes returnGPR. 3) Started moving FTL towards the same templated operation signature deduction of arguments used in the other JITs. 4) exception checks have been pushed into callOperation in DFG since that has the signature of the operation being called already. 5) We don't support exceptions in registers for double on ARM64 since that causes the double to be returned in x0 rather than d0. Also, FTL doesn't
[webkit-changes] [WebKit/WebKit] 10748e: JIT operations should return the current exception...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 10748e5975cd1f538bd71b5e68bcf61ad142fc18 https://github.com/WebKit/WebKit/commit/10748e5975cd1f538bd71b5e68bcf61ad142fc18 Author: Keith Miller Date: 2024-05-07 (Tue, 07 May 2024) Changed paths: M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/assembler/MacroAssembler.h M Source/JavaScriptCore/assembler/MacroAssemblerARM64.cpp M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.cpp M Source/JavaScriptCore/assembler/MacroAssemblerRISCV64.cpp M Source/JavaScriptCore/assembler/MacroAssemblerX86Common.cpp M Source/JavaScriptCore/b3/B3Type.h M Source/JavaScriptCore/b3/B3Validate.cpp M Source/JavaScriptCore/b3/air/AirCCallingConvention.cpp M Source/JavaScriptCore/b3/testb3.h M Source/JavaScriptCore/b3/testb3_5.cpp M Source/JavaScriptCore/b3/testb3_6.cpp M Source/JavaScriptCore/b3/testb3_7.cpp M Source/JavaScriptCore/dfg/DFGAbstractInterpreter.h M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h M Source/JavaScriptCore/dfg/DFGArithMode.h M Source/JavaScriptCore/dfg/DFGArrayifySlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp M Source/JavaScriptCore/dfg/DFGCallArrayAllocatorSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGJITCompiler.h M Source/JavaScriptCore/dfg/DFGOSRExit.cpp M Source/JavaScriptCore/dfg/DFGOSRExit.h M Source/JavaScriptCore/dfg/DFGOperations.cpp M Source/JavaScriptCore/dfg/DFGOperations.h M Source/JavaScriptCore/dfg/DFGSaneStringGetByValSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.h M Source/JavaScriptCore/ftl/FTLOperations.cpp M Source/JavaScriptCore/ftl/FTLOperations.h M Source/JavaScriptCore/ftl/FTLOutput.cpp M Source/JavaScriptCore/ftl/FTLOutput.h M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.h M Source/JavaScriptCore/jit/CCallHelpers.h M Source/JavaScriptCore/jit/JIT.h M Source/JavaScriptCore/jit/JITCall.cpp M Source/JavaScriptCore/jit/JITInlines.h M Source/JavaScriptCore/jit/JITOperations.cpp M Source/JavaScriptCore/jit/JITOperations.h A Source/JavaScriptCore/jit/OperationResult.h M Source/JavaScriptCore/llint/LLIntThunks.h M Source/JavaScriptCore/runtime/AtomicsObject.cpp M Source/JavaScriptCore/runtime/CommonSlowPaths.h M Source/JavaScriptCore/runtime/ExceptionScope.h M Source/JavaScriptCore/runtime/HashMapImplInlines.h M Source/JavaScriptCore/runtime/MathCommon.cpp M Source/JavaScriptCore/runtime/MathCommon.h M Source/JavaScriptCore/runtime/StringPrototype.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmOperations.h M Source/JavaScriptCore/yarr/YarrJIT.cpp M Source/WTF/wtf/PlatformCallingConventions.h M Source/WTF/wtf/Threading.cpp M Source/WebCore/bindings/scripts/CodeGeneratorJS.pm M Source/WebCore/bindings/scripts/test/JS/JSTestDOMJIT.cpp M Source/WebCore/cssjit/SelectorCompiler.cpp M Source/WebCore/domjit/JSDocumentDOMJIT.cpp Log Message: --- JIT operations should return the current exception in a return GPR when it's free. https://bugs.webkit.org/show_bug.cgi?id=273264 rdar://127065985 Reviewed by Yusuke Suzuki. Reland: Move operationExceptionRegister to CCallHelpers because including GPRInfo.h in OperationResult.h cause downstream build issues. This patch makes a lot of changes so that we can pass the current exception in a return register. 1) There's now a new set of macros for JIT_OPERATIONS that wrap the return type in a templated struct containing the true result and a pointer to the current exception if there's an extra return register in the C++ calling convention (and returning a `struct` won't push everything to the stack... armv7...). 2) Exception checking macro assembler functions take an optional register parameter, which is the register the exception is in, typically returnGPR2 but sometimes returnGPR. 3) Started moving FTL towards the same templated operation signature deduction of arguments used in the other JITs. 4) exception checks have been pushed into callOperation in DFG since that has the signature of the operation being called already. 5) We don't suppor
[webkit-changes] [WebKit/WebKit] 65ee80: direct eval operations should use their caller's c...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 65ee8082f55782b90fe07e43fd44150a2d7e04f5 https://github.com/WebKit/WebKit/commit/65ee8082f55782b90fe07e43fd44150a2d7e04f5 Author: Keith Miller Date: 2024-05-10 (Fri, 10 May 2024) Changed paths: A JSTests/stress/direct-eval-set-to-42.js M Source/JavaScriptCore/jit/JITOperations.cpp Log Message: --- direct eval operations should use their caller's callee to get the VM https://bugs.webkit.org/show_bug.cgi?id=273979 rdar://127766799 Reviewed by Yusuke Suzuki. Since `eval` could be set to anything, including a non-cell primitive, we can't use it get a VM. The caller's frame should have a real callee though so we use that instead. * JSTests/stress/direct-eval-set-to-42.js: Added. (foo): (bar): * Source/JavaScriptCore/jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): Canonical link: https://commits.webkit.org/278612@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 350878: Reduce String ref/deref churn in JSC by 60% on Jet...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 350878c832f8c798c309d5f28655bec537754fc0 https://github.com/WebKit/WebKit/commit/350878c832f8c798c309d5f28655bec537754fc0 Author: Keith Miller Date: 2024-05-13 (Mon, 13 May 2024) Changed paths: M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/bytecode/Repatch.cpp M Source/JavaScriptCore/dfg/DFGOperations.cpp M Source/JavaScriptCore/ftl/FTLOperations.cpp A Source/JavaScriptCore/heap/GCOwnedDataScope.h M Source/JavaScriptCore/inspector/InjectedScriptBase.cpp M Source/JavaScriptCore/inspector/JSInjectedScriptHost.cpp M Source/JavaScriptCore/inspector/JSJavaScriptCallFrame.cpp M Source/JavaScriptCore/interpreter/Interpreter.cpp M Source/JavaScriptCore/jit/ICStats.h M Source/JavaScriptCore/jit/JITArithmetic.cpp M Source/JavaScriptCore/jit/JITOperations.cpp M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp M Source/JavaScriptCore/runtime/ArrayPrototype.cpp M Source/JavaScriptCore/runtime/CachedTypes.cpp M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp M Source/JavaScriptCore/runtime/DateConstructor.cpp M Source/JavaScriptCore/runtime/ErrorInstance.cpp M Source/JavaScriptCore/runtime/ErrorInstance.h M Source/JavaScriptCore/runtime/ExceptionHelpers.cpp M Source/JavaScriptCore/runtime/ExceptionScope.cpp M Source/JavaScriptCore/runtime/FunctionConstructor.cpp M Source/JavaScriptCore/runtime/HashMapImplInlines.h M Source/JavaScriptCore/runtime/IntlCollatorPrototype.cpp M Source/JavaScriptCore/runtime/IntlNumberFormatInlines.h M Source/JavaScriptCore/runtime/IntlSegmenter.cpp M Source/JavaScriptCore/runtime/JSBoundFunction.cpp M Source/JavaScriptCore/runtime/JSCJSValue.cpp M Source/JavaScriptCore/runtime/JSCJSValueInlines.h M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp M Source/JavaScriptCore/runtime/JSImmutableButterfly.cpp M Source/JavaScriptCore/runtime/JSModuleLoader.cpp M Source/JavaScriptCore/runtime/JSONObject.cpp M Source/JavaScriptCore/runtime/JSObject.cpp M Source/JavaScriptCore/runtime/JSString.cpp M Source/JavaScriptCore/runtime/JSString.h M Source/JavaScriptCore/runtime/JSStringInlines.h M Source/JavaScriptCore/runtime/JSStringJoiner.h M Source/JavaScriptCore/runtime/NumberPrototype.cpp M Source/JavaScriptCore/runtime/Operations.h M Source/JavaScriptCore/runtime/ParseInt.h M Source/JavaScriptCore/runtime/PropertyName.h M Source/JavaScriptCore/runtime/RegExpConstructor.cpp M Source/JavaScriptCore/runtime/RegExpMatchesArray.h M Source/JavaScriptCore/runtime/RegExpObject.cpp M Source/JavaScriptCore/runtime/RegExpObjectInlines.h M Source/JavaScriptCore/runtime/RegExpPrototype.cpp M Source/JavaScriptCore/runtime/ShadowRealmPrototype.cpp M Source/JavaScriptCore/runtime/StringPrototype.cpp M Source/JavaScriptCore/runtime/StringPrototypeInlines.h M Source/JavaScriptCore/runtime/SymbolConstructor.cpp M Source/JavaScriptCore/runtime/TemporalCalendarPrototype.cpp M Source/JavaScriptCore/runtime/TemporalPlainTime.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/WTF/wtf/HashMap.h M Source/WTF/wtf/text/WTFString.h M Source/WebCore/bindings/js/SerializedScriptValue.cpp M Source/WebCore/bridge/objc/WebScriptObject.mm M Source/WebKitLegacy/mac/WebView/WebView.mm Log Message: --- Reduce String ref/deref churn in JSC by 60% on JetStream2 https://bugs.webkit.org/show_bug.cgi?id=274046 rdar://127946516 Reviewed by Yusuke Suzuki. This patch reduces the number of refs in JSC on JetStream2 by ~60% from 407831951 to 168560273, which seems to be ~.3% speedup on that benchmark. Mostly this is done by introducing a new class `GCOwnedDataScope` this class holds some data owned by a GCed object and ensures that GCed object is retained by the C++ compiler at least as long as the scope. This makes it easy to provide access to GC object owned data safely. The only requirement is that people **DO NOT** do `Data&/* data = gcType->getData()`. However, this is the problem with the current accessors used throughout JSC anyway. Over time we should start migrating more and more JSC accessor member functions to `GCOwnedDataScope`. The main functions updated in this patch are `JSString::value` and `JSString::viewWithUnderlyingString` the latter of which is now JSString::view. These now return a `GCOwnedDataScope` and `GCOwnedDataScope`, respectively. Additionally, PropertyName now takes a CacheableIdentifier for the various `operationGetBy` JIT operations instead of converting to a true Identifier (incurring a ref/deref). Also, add some extra logging to ou
[webkit-changes] [WebKit/WebKit] 8b9188: Fix typo LLintToWasmEntryPtrTag -> LLIntToWasmEntr...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 8b9188bd1f89b826b74c759c02b64449a9a9f929 https://github.com/WebKit/WebKit/commit/8b9188bd1f89b826b74c759c02b64449a9a9f929 Author: Keith Miller Date: 2024-05-13 (Mon, 13 May 2024) Changed paths: M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/llint/WebAssembly.asm M Source/JavaScriptCore/runtime/JSCPtrTag.h M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmCallee.h Log Message: --- Fix typo LLintToWasmEntryPtrTag -> LLIntToWasmEntryPtrTag https://bugs.webkit.org/show_bug.cgi?id=274103 rdar://128014907 Reviewed by Yusuke Suzuki. * Source/JavaScriptCore/llint/LowLevelInterpreter.asm: * Source/JavaScriptCore/llint/WebAssembly.asm: * Source/JavaScriptCore/runtime/JSCPtrTag.h: * Source/JavaScriptCore/wasm/WasmCallee.cpp: (JSC::Wasm::JSEntrypointInterpreterCallee::JSEntrypointInterpreterCallee): * Source/JavaScriptCore/wasm/WasmCallee.h: Canonical link: https://commits.webkit.org/278709@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 19a88e: Cherry-pick 139468088633. rdar://127862273
Branch: refs/heads/safari-7619.1.13-branch Home: https://github.com/WebKit/WebKit Commit: 19a88e9f24ec715d76c64dd59a8ac369698ddbe5 https://github.com/WebKit/WebKit/commit/19a88e9f24ec715d76c64dd59a8ac369698ddbe5 Author: Dan Glastonbury Date: 2024-05-10 (Fri, 10 May 2024) Changed paths: M Source/WebKit/Platform/ios/PlaybackSessionInterfaceLMK.h M Source/WebKit/Platform/ios/PlaybackSessionInterfaceLMK.mm M Source/WebKit/Platform/ios/VideoPresentationInterfaceLMK.h M Source/WebKit/Platform/ios/VideoPresentationInterfaceLMK.mm Log Message: --- Cherry-pick 139468088633. rdar://127862273 Unreviewed, fix the visionOS build after 278598@main https://bugs.webkit.org/show_bug.cgi?id=273990 rdar://127862273 Unreviewed build fix. Prefix all the things with WebCore:: after using namespace WebCore was removed. * Source/WebKit/Platform/ios/PlaybackSessionInterfaceLMK.h: * Source/WebKit/Platform/ios/PlaybackSessionInterfaceLMK.mm: (-[WKLinearMediaPlayerDelegate initWithModel:]): (WebKit::PlaybackSessionInterfaceLMK::create): (WebKit::PlaybackSessionInterfaceLMK::PlaybackSessionInterfaceLMK): (WebKit::PlaybackSessionInterfaceLMK::rateChanged): (WebKit::PlaybackSessionInterfaceLMK::seekableRangesChanged): (WebKit::PlaybackSessionInterfaceLMK::audioMediaSelectionOptionsChanged): (WebKit::PlaybackSessionInterfaceLMK::legibleMediaSelectionOptionsChanged): * Source/WebKit/Platform/ios/VideoPresentationInterfaceLMK.h: * Source/WebKit/Platform/ios/VideoPresentationInterfaceLMK.mm: (WebKit::VideoPresentationInterfaceLMK::create): (WebKit::VideoPresentationInterfaceLMK::VideoPresentationInterfaceLMK): (WebKit::VideoPresentationInterfaceLMK::setupFullscreen): (WebKit::VideoPresentationInterfaceLMK::setContentDimensions): (WebKit::VideoPresentationInterfaceLMK::setupCaptionsLayer): Canonical link: https://commits.webkit.org/278604@main Canonical link: https://commits.webkit.org/278598.1@safari-7619.1.13-branch Commit: 5ca9eaaf4348829c3be3f1fe973f60621fe062a9 https://github.com/WebKit/WebKit/commit/5ca9eaaf4348829c3be3f1fe973f60621fe062a9 Author: Keith Miller Date: 2024-05-10 (Fri, 10 May 2024) Changed paths: A JSTests/stress/direct-eval-set-to-42.js M Source/JavaScriptCore/jit/JITOperations.cpp Log Message: --- Cherry-pick 65ee8082f557. rdar://127766799 direct eval operations should use their caller's callee to get the VM https://bugs.webkit.org/show_bug.cgi?id=273979 rdar://127766799 Reviewed by Yusuke Suzuki. Since `eval` could be set to anything, including a non-cell primitive, we can't use it get a VM. The caller's frame should have a real callee though so we use that instead. * JSTests/stress/direct-eval-set-to-42.js: Added. (foo): (bar): * Source/JavaScriptCore/jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): Canonical link: https://commits.webkit.org/278612@main Canonical link: https://commits.webkit.org/278598.2@safari-7619.1.13-branch Compare: https://github.com/WebKit/WebKit/compare/19a88e9f24ec%5E...5ca9eaaf4348 To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ae8102: Changing a JSFunction's prototype property should ...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: ae8102d789a8b5099ace514572f80afbcb9065d6 https://github.com/WebKit/WebKit/commit/ae8102d789a8b5099ace514572f80afbcb9065d6 Author: Keith Miller Date: 2024-05-16 (Thu, 16 May 2024) Changed paths: A JSTests/stress/bound-constructor-change-prototype-clears-cache.js A JSTests/stress/put-prototype-to-normal-function-shouldnt-be-cached.js M Source/JavaScriptCore/bytecode/InternalFunctionAllocationProfile.h M Source/JavaScriptCore/bytecode/ObjectAllocationProfileInlines.h M Source/JavaScriptCore/dfg/DFGOperations.cpp M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp M Source/JavaScriptCore/runtime/FunctionRareData.h M Source/JavaScriptCore/runtime/InternalFunction.cpp M Source/JavaScriptCore/runtime/JSFunction.cpp M Source/JavaScriptCore/runtime/JSFunction.h M Source/JavaScriptCore/runtime/JSFunctionInlines.h Log Message: --- Changing a JSFunction's prototype property should clear allocation caches https://bugs.webkit.org/show_bug.cgi?id=270302 rdar://121657868 Reviewed by Alexey Shvayka and Yusuke Suzuki. Right now we only clear the allocation watchpoint if a JSFunction `mayHaveNonReifiedPrototype()` when setting the .prototype property. This is semantically incorrect in the case of `new.target` bound functions because we will cache the wrong value. This patch makes it so we always file the allocation profile watchpoint when turning either of the allocation profiles. When turning the ObjectAllocationProfile (used by op_create_this) we assert the watchpoint has already been fired as it should've already happened when the new .prototype value was set. When turning the InternalFunctionAllocationProfile (used by createSubclassStructure when subclassing InternalFunction/Reflect.construct) its possible to pass the same JSFunction to two different InternalFunctions, which will turn the profile. * JSTests/stress/bound-constructor-change-prototype-clears-cache.js: Added. (empty): (test1.const.newTarget): (test1): (test2.const.newTarget): (test2.Opt): (test2): (test3.const.newTarget): (main): * JSTests/stress/put-prototype-to-normal-function-shouldnt-be-cached.js: Added. (opt): (main.target): (main): * Source/JavaScriptCore/bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase): * Source/JavaScriptCore/bytecode/ObjectAllocationProfileInlines.h: (JSC::ObjectAllocationProfileBase::initializeProfile): * Source/JavaScriptCore/dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): (JSC::createInternalFieldObject): * Source/JavaScriptCore/runtime/FunctionRareData.h: * Source/JavaScriptCore/runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructure): * Source/JavaScriptCore/runtime/JSFunction.cpp: (JSC::JSFunction::prototypeForConstruction): (JSC::JSFunction::allocateAndInitializeRareData): (JSC::JSFunction::initializeRareData): (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * Source/JavaScriptCore/runtime/JSFunction.h: * Source/JavaScriptCore/runtime/JSFunctionInlines.h: (JSC::JSFunction::canUseAllocationProfiles): (JSC::JSFunction::ensureRareDataAndObjectAllocationProfile): (JSC::JSFunction::canUseAllocationProfile): Deleted. (JSC::JSFunction::ensureRareDataAndAllocationProfile): Deleted. Originally-landed-as: 272448.699@safari-7618-branch (96283e8a5f10). rdar://128089585 Canonical link: https://commits.webkit.org/278869@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 479314: Style checker shouldn't complain about `requires (...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 479314b7018c909d99dcff4714b6ec2171652339 https://github.com/WebKit/WebKit/commit/479314b7018c909d99dcff4714b6ec2171652339 Author: Keith Miller Date: 2024-05-17 (Fri, 17 May 2024) Changed paths: M Tools/Scripts/webkitpy/style/checkers/cpp.py M Tools/Scripts/webkitpy/style/checkers/cpp_unittest.py Log Message: --- Style checker shouldn't complain about `requires (MyConcept)` https://bugs.webkit.org/show_bug.cgi?id=274324 rdar://128284081 Reviewed by Jonathan Bedard. Right now the style checker will complain about an extra space before the arguments to a function call when you do `requires (MyConcept)`. We should treat spaces after `requires` the same way we treat spaces after other keywords. * Tools/Scripts/webkitpy/style/checkers/cpp.py: (check_spacing_for_function_call): * Tools/Scripts/webkitpy/style/checkers/cpp_unittest.py: (WebKitStyleTest.test_spacing): Canonical link: https://commits.webkit.org/278922@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 9a2f01: Rebaseline intl tests for latest ICU
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 9a2f01e883bb3b393d9a8d17532c7c462ef52cb3 https://github.com/WebKit/WebKit/commit/9a2f01e883bb3b393d9a8d17532c7c462ef52cb3 Author: Keith Miller Date: 2024-05-18 (Sat, 18 May 2024) Changed paths: M JSTests/stress/intl-datetimeformat.js M JSTests/stress/intl-numberformat.js Log Message: --- Rebaseline intl tests for latest ICU https://bugs.webkit.org/show_bug.cgi?id=274339 rdar://128296361 Unreviewed, rebaseline intl tests. * JSTests/stress/intl-datetimeformat.js: * JSTests/stress/intl-numberformat.js: (shouldBeOneOf): Canonical link: https://commits.webkit.org/278954@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 16709e: Fix exception Fuzz in Baseline/DFG with exception ...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 16709ef06aca82c4f2ab72e63cce4d2981e2cf59 https://github.com/WebKit/WebKit/commit/16709ef06aca82c4f2ab72e63cce4d2981e2cf59 Author: Keith Miller Date: 2024-05-18 (Sat, 18 May 2024) Changed paths: M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.h Log Message: --- Fix exception Fuzz in Baseline/DFG with exception return registers https://bugs.webkit.org/show_bug.cgi?id=274315 rdar://128230658 Reviewed by Mark Lam. Baseline/DFG `emitExceptionCheck` didn't forward the exception register it's going to use to `callExceptionFuzz` so it could get out of sync with the fuzzers state. Now `callExceptionFuzz` will properly fill the exception register with the new exception if it's set. * Source/JavaScriptCore/jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::callExceptionFuzz): (JSC::AssemblyHelpers::emitExceptionCheck): * Source/JavaScriptCore/jit/AssemblyHelpers.h: Canonical link: https://commits.webkit.org/278956@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 3e3d08: Make it harder to get a PAC signing gadget in JIT ...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 3e3d0883c84955472ece1b2f2e63f31522c5440d https://github.com/WebKit/WebKit/commit/3e3d0883c84955472ece1b2f2e63f31522c5440d Author: Keith Miller Date: 2024-05-20 (Mon, 20 May 2024) Changed paths: M Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h M Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp M Source/JavaScriptCore/jit/ThunkGenerators.cpp M Source/JavaScriptCore/llint/LLIntThunks.cpp M Source/JavaScriptCore/runtime/Options.cpp M Source/JavaScriptCore/runtime/OptionsList.h M Source/WTF/wtf/PtrTag.h M Source/WebKit/WebProcess/WebProcess.cpp M Tools/Scripts/run-jsc-stress-tests Log Message: --- Make it harder to get a PAC signing gadget in JIT code. https://bugs.webkit.org/show_bug.cgi?id=272750 rdar://125596635 Reviewed by Yusuke Suzuki. Right now if an attacker can control where code is allocated they can overlap code to create a PAC bypass. This patch makes that harder (in the WebContent process) by only allowing pacibsp and pacizb. This means that during arity fixup we now tag the return PC with pacizb. This is ok because we don't use the zero diversifier for anything. For reifying inlined call frames during OSR exit things are a bit more complicated. First we have be careful to only move signed return addresses into lr then untag them there. Also, we have to shuffle SP to point to where it would in reified frame. This means that there is technically live data below our SP, which on many OSes causes problems. Talking to our kernel folks however this isn't a problem as long as we don't have any signal handlers or run lldb expressions in this window. We don't use signal handlers in the WebContent process and this patch tries to limit/document the window of JIT code where lldb would trash the stack. * Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h: (JSC::MacroAssemblerARM64E::tagPtr): * Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): (JSC::AssemblyHelpers::transferReturnPC): * Source/JavaScriptCore/jit/ThunkGenerators.cpp: (JSC::arityFixupGenerator): * Source/JavaScriptCore/llint/LLIntThunks.cpp: (JSC::LLInt::tagGateThunk): (JSC::LLInt::untagGateThunk): * Source/JavaScriptCore/runtime/OptionsList.h: * Source/WTF/wtf/PtrTag.h: * Source/WebKit/WebProcess/WebProcess.cpp: (WebKit::WebProcess::initializeProcess): * Tools/Scripts/run-jsc-stress-tests: Originally-landed-as: f442fbe222f3. rdar://128091836 Canonical link: https://commits.webkit.org/278996@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] d1282e: exceptions can't always be checked under silent sp...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: d1282e05222cf31b112823d5c8a08632d5ff0558 https://github.com/WebKit/WebKit/commit/d1282e05222cf31b112823d5c8a08632d5ff0558 Author: Keith Miller Date: 2024-05-20 (Mon, 20 May 2024) Changed paths: M JSTests/stress/generator-cell-with-type.js A JSTests/stress/stack-overflow-in-scope-with-catch.js M Source/JavaScriptCore/Scripts/process-entitlements.sh M Source/JavaScriptCore/dfg/DFGArrayifySlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallArrayAllocatorSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGRegisterBank.h M Source/JavaScriptCore/dfg/DFGSaneStringGetByValSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSilentRegisterSavePlan.h M Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/GPRInfo.h M Source/JavaScriptCore/jit/OperationResult.h M Source/JavaScriptCore/jit/Reg.h M Source/JavaScriptCore/jit/RegisterSet.h Log Message: --- exceptions can't always be checked under silent spill in DFG https://bugs.webkit.org/show_bug.cgi?id=274291 rdar://128067350 Reviewed by Yusuke Suzuki. If we're catching an exception in the same DFG frame it's potentially not safe to check for exceptions under a silent spill. This is because the OSR exit ramp does not know about the silent spill. So values will not be restored. There were a couple of possible fixes: 1) teach the DFGVariableEventStream about exceptions under silent spill. 2) add extra metadata about the fact we’re under a silent spill and silent fill before hitting the OSR exit ramp. 3) move the exception to an unused gpr until we can silent fill if needed. I went with option 3. 1. has the problem that it's complicated and might be a memory regression. 2. could bloat code size. I also noticed that my `requires (!OperationHasResult)` checks were not properly eliminating overloads. This is because when you do e.g. `requires (!OperationHasResult)` the `OperationHasResult` will fail SFINAE but that just makes the concept false which then becomes true in the requirement. Instead we now have a new `OperationIsVoid` concept. * JSTests/stress/stack-overflow-in-scope-with-catch.js: Added. (foo.catch.Set.Symbol.hasInstance): (foo.finally.bar): (foo.goo.baz): (foo.goo): (foo): * Source/JavaScriptCore/dfg/DFGArrayifySlowPathGenerator.h: * Source/JavaScriptCore/dfg/DFGCallArrayAllocatorSlowPathGenerator.h: * Source/JavaScriptCore/dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: * Source/JavaScriptCore/dfg/DFGSaneStringGetByValSlowPathGenerator.h: * Source/JavaScriptCore/dfg/DFGSilentRegisterSavePlan.h: (JSC::DFG::SilentRegisterSavePlan::SilentRegisterSavePlan): (JSC::DFG::SilentRegisterSavePlan::reg const): (JSC::DFG::SilentRegisterSavePlan::gpr const): (JSC::DFG::SilentRegisterSavePlan::fpr const): * Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h: (JSC::DFG::CallSlowPathGenerator::setUp): (JSC::DFG::CallSlowPathGenerator::tearDown): * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::exceptionCheck): (JSC::DFG::SpeculativeJIT::silentSpillImpl): (JSC::DFG::SpeculativeJIT::silentFillImpl): (JSC::DFG::SpeculativeJIT::compileToLowerCase): (JSC::DFG::SpeculativeJIT::silentSpill): Deleted. (JSC::DFG::SpeculativeJIT::silentFill): Deleted. * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::spillPlanInterferesWithReg): (JSC::DFG::SpeculativeJIT::silentSpill): (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::silentSpillAllRegistersImpl): (JSC::DFG::SpeculativeJIT::silentFillAllRegisters): (JSC::DFG::SpeculativeJIT::operationExceptionCheck): (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::SpeculativeJIT::tryHandleOrGetExceptionUnderSilentSpill): (JSC::DFG::SpeculativeJIT::callOperationWithSilentSpill): * Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::genericJSValueNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compileGetByVal): (JSC::DFG::SpeculativeJIT::compile): * Source/JavaScriptCore/jit/GPRInfo.h: (JSC::NoOverlapImpl::noOverlapImpl): * Source/JavaScriptCore/jit/OperationResult.h: * Source/JavaScriptCore/jit/Reg.h: Canonical link: https://commits.webkit.org/279031@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 59ee46: JetStreamDriver cli mode shouldn't print status if...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 59ee4600231b781d7b520e4faebf0675a1780456 https://github.com/WebKit/WebKit/commit/59ee4600231b781d7b520e4faebf0675a1780456 Author: Keith Miller Date: 2024-05-21 (Tue, 21 May 2024) Changed paths: M PerformanceTests/JetStream2/JetStreamDriver.js Log Message: --- JetStreamDriver cli mode shouldn't print status if dumping JSON https://bugs.webkit.org/show_bug.cgi?id=274487 rdar://128494817 Reviewed by Yusuke Suzuki. Right now running the JetStream2 cli from the command line prints status updates even when dumpJSONResults is truthy. This makes it hard to do `jsc -e "dumpJSONResults=1" cli.js > results.json` since the top of the file will have a bunch of status updates. This patch silences status updates when dumpJSONResults is truthy. Also, `customTestList` is now only intialized to `[]` if it's not already set so we can now do `jsc -e "customTestList=['Air']" cli.js` * PerformanceTests/JetStream2/JetStreamDriver.js: (Driver.prototype.async start): (prototype.updateUIBeforeRun): (DefaultBenchmark.prototype.updateUIAfterRun): (DefaultBenchmark): (WSLBenchmark.prototype.updateUIAfterRun): (WSLBenchmark): (WasmBenchmark.prototype.updateUIAfterRun): (WasmBenchmark): (Driver.async fetchResources.statusElement.innerHTML.a.href.string_appeared_here): (Driver.prototype.async fetchResources): Canonical link: https://commits.webkit.org/279095@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 3a6e63: Fix linker error in JSC testing configuration
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 3a6e636fb3bed4bda1a737658411a2af43c86e00 https://github.com/WebKit/WebKit/commit/3a6e636fb3bed4bda1a737658411a2af43c86e00 Author: Keith Miller Date: 2024-05-22 (Wed, 22 May 2024) Changed paths: M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp M Source/JavaScriptCore/bytecode/UnlinkedMetadataTableInlines.h Log Message: --- Fix linker error in JSC testing configuration https://bugs.webkit.org/show_bug.cgi?id=274523 rdar://128542072 Reviewed by Mark Lam. It seems like someone holding a Ref/RefPtr to UnlinkedMetadataTable didn't include the inlines header. Rather than figure out how to find the missing include I just moved the destructor to the .cpp file. I don't think the destructor is hot enough that inlining is needed. * Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp: (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): * Source/JavaScriptCore/bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): Deleted. Canonical link: https://commits.webkit.org/279126@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ea2439: Versioning.
: (WebKit::XPCServiceEventHandler): Canonical link: https://commits.webkit.org/277509@main Commit: 66b2665acc10dd7202645d8b212f647aada6762e https://github.com/WebKit/WebKit/commit/66b2665acc10dd7202645d8b212f647aada6762e Author: Per Arne Vollan Date: 2024-04-17 (Wed, 17 Apr 2024) Changed paths: M Source/WebKit/Platform/cocoa/XPCUtilities.mm Log Message: --- Cherry-pick 1bfeac262aa5. rdar://126479653 Compile fix after <https://commits.webkit.org/277509@main> https://bugs.webkit.org/show_bug.cgi?id=272824 rdar://126479653 Unreviewed compile fix. * Source/WebKit/Platform/cocoa/XPCUtilities.mm: Canonical link: https://commits.webkit.org/277621@main Commit: 92b8d408b1f9658808dd21758df668195f20c3c6 https://github.com/WebKit/WebKit/commit/92b8d408b1f9658808dd21758df668195f20c3c6 Author: Mohsin Qureshi Date: 2024-04-17 (Wed, 17 Apr 2024) Changed paths: M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/bytecode/ExpressionInfo.h M Source/JavaScriptCore/runtime/CachedTypes.cpp M Source/JavaScriptCore/runtime/FileBasedFuzzerAgentBase.h A Source/JavaScriptCore/runtime/JSCBytecodeCacheVersion.cpp R Source/JavaScriptCore/runtime/JSCBytecodeCacheVersion.cpp.in M Source/JavaScriptCore/runtime/JSCBytecodeCacheVersion.h M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp M Source/WTF/wtf/spi/darwin/dyldSPI.h Log Message: --- Apply patch. rdar://126195542 Commit: a6f1d0aa1f343e915ba446d337ec720ba8310b1f https://github.com/WebKit/WebKit/commit/a6f1d0aa1f343e915ba446d337ec720ba8310b1f Author: Mohsin Qureshi Date: 2024-04-17 (Wed, 17 Apr 2024) Changed paths: M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/bytecode/ExpressionInfo.h M Source/JavaScriptCore/runtime/CachedTypes.cpp M Source/JavaScriptCore/runtime/FileBasedFuzzerAgentBase.h R Source/JavaScriptCore/runtime/JSCBytecodeCacheVersion.cpp A Source/JavaScriptCore/runtime/JSCBytecodeCacheVersion.cpp.in M Source/JavaScriptCore/runtime/JSCBytecodeCacheVersion.h M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp M Source/WTF/wtf/spi/darwin/dyldSPI.h Log Message: --- Revert "Apply patch. rdar://126195542" This reverts commit 92b8d408b1f9658808dd21758df668195f20c3c6. Commit: e7cb80cb98d995a71bb29eae929183aa008ead5f https://github.com/WebKit/WebKit/commit/e7cb80cb98d995a71bb29eae929183aa008ead5f Author: Mohsin Qureshi Date: 2024-04-17 (Wed, 17 Apr 2024) Changed paths: M Source/WebKit/Platform/cocoa/XPCUtilities.mm Log Message: --- Revert "Cherry-pick 1bfeac262aa5. rdar://126479653" This reverts commit 66b2665acc10dd7202645d8b212f647aada6762e. Commit: dbfb1cdd989125f7c728d08c0a2d00cb3c117dfe https://github.com/WebKit/WebKit/commit/dbfb1cdd989125f7c728d08c0a2d00cb3c117dfe Author: Mohsin Qureshi Date: 2024-04-17 (Wed, 17 Apr 2024) Changed paths: M Source/WebKit/Platform/cocoa/XPCUtilities.h M Source/WebKit/Platform/cocoa/XPCUtilities.mm M Source/WebKit/Shared/Authentication/cocoa/AuthenticationManagerCocoa.mm M Source/WebKit/Shared/Cocoa/XPCEndpoint.mm M Source/WebKit/Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm Log Message: --- Revert "Cherry-pick 3c2c899f692d. rdar://126479653" This reverts commit d7e2f94c57ea9901695253d7882747b6f62b6ab8. Commit: 6ce501a2bff07d473dc2f57cbbde83e6c88108d1 https://github.com/WebKit/WebKit/commit/6ce501a2bff07d473dc2f57cbbde83e6c88108d1 Author: Keith Miller Date: 2024-04-22 (Mon, 22 Apr 2024) Changed paths: M Source/JavaScriptCore/assembler/MacroAssemblerARM64E.h M Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp M Source/JavaScriptCore/jit/ThunkGenerators.cpp M Source/JavaScriptCore/llint/LLIntThunks.cpp M Source/JavaScriptCore/runtime/Options.cpp M Source/JavaScriptCore/runtime/OptionsList.h M Source/WTF/wtf/PtrTag.h M Source/WebKit/WebProcess/WebProcess.cpp M Tools/Scripts/run-jsc-stress-tests Log Message: --- Cherry-pick f442fbe222f3. rdar://125596635 Make it harder to get a PAC signing gadget in JIT code. https://bugs.webkit.org/show_bug.cgi?id=272750 rdar://125596635 Reviewed by Yusuke Suzuki. Right now if an attacker can control where code is allocated they can overlap code to create a PAC bypass. This patch makes that harder (in the WebContent process) by only allowing pacibsp and pacizb. This means that during arity fixup we now tag the return PC with pacizb. This is ok because we don't use the zero
[webkit-changes] [WebKit/WebKit] 7031a9: OBJECT_OFFSETOF can be constexpr
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 7031a92238c3270b0db68337921a5b30d5965e91 https://github.com/WebKit/WebKit/commit/7031a92238c3270b0db68337921a5b30d5965e91 Author: Keith Miller Date: 2024-05-23 (Thu, 23 May 2024) Changed paths: M Source/JavaScriptCore/assembler/MacroAssemblerCodeRef.h M Source/JavaScriptCore/bytecode/ArrayProfile.h M Source/JavaScriptCore/bytecode/CallLinkInfo.h M Source/JavaScriptCore/bytecode/CallLinkInfoBase.h M Source/JavaScriptCore/bytecode/CodeBlock.h M Source/JavaScriptCore/bytecode/GetByIdMetadata.h M Source/JavaScriptCore/bytecode/InlineCacheCompiler.h M Source/JavaScriptCore/bytecode/IterationModeMetadata.h M Source/JavaScriptCore/bytecode/ObjectAllocationProfile.h M Source/JavaScriptCore/bytecode/StructureStubInfo.h M Source/JavaScriptCore/bytecode/ValueProfile.h M Source/JavaScriptCore/bytecode/Watchpoint.h M Source/JavaScriptCore/dfg/DFGCommonData.h M Source/JavaScriptCore/dfg/DFGJITCode.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp M Source/JavaScriptCore/ftl/FTLJITCode.h M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/generator/Metadata.rb M Source/JavaScriptCore/heap/CompleteSubspace.h M Source/JavaScriptCore/heap/FreeList.h M Source/JavaScriptCore/heap/LocalAllocator.h M Source/JavaScriptCore/heap/MarkedBlock.h M Source/JavaScriptCore/heap/PreciseAllocation.h M Source/JavaScriptCore/heap/TinyBloomFilter.h M Source/JavaScriptCore/heap/WeakImpl.h M Source/JavaScriptCore/heap/WeakSet.h M Source/JavaScriptCore/interpreter/CallFrame.h M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/BaselineJITCode.h M Source/JavaScriptCore/jit/JIT.cpp M Source/JavaScriptCore/jit/JITCode.h M Source/JavaScriptCore/jit/ThunkGenerators.cpp M Source/JavaScriptCore/llint/LLIntData.cpp M Source/JavaScriptCore/runtime/ArrayBuffer.h M Source/JavaScriptCore/runtime/ArrayStorage.h M Source/JavaScriptCore/runtime/BufferMemoryHandle.h M Source/JavaScriptCore/runtime/Butterfly.h M Source/JavaScriptCore/runtime/CachedTypes.cpp M Source/JavaScriptCore/runtime/CachedTypes.h M Source/JavaScriptCore/runtime/ClassInfo.h M Source/JavaScriptCore/runtime/ClonedArguments.h M Source/JavaScriptCore/runtime/DateInstance.h M Source/JavaScriptCore/runtime/DateInstanceCache.h M Source/JavaScriptCore/runtime/DirectArguments.h M Source/JavaScriptCore/runtime/Exception.h M Source/JavaScriptCore/runtime/ExecutableBase.h M Source/JavaScriptCore/runtime/FunctionExecutable.h M Source/JavaScriptCore/runtime/GetterSetter.h M Source/JavaScriptCore/runtime/HasOwnPropertyCache.h M Source/JavaScriptCore/runtime/HashMapImpl.h M Source/JavaScriptCore/runtime/IndexingHeader.h M Source/JavaScriptCore/runtime/InternalFunction.h M Source/JavaScriptCore/runtime/JSArrayBufferView.h M Source/JavaScriptCore/runtime/JSBoundFunction.h M Source/JavaScriptCore/runtime/JSCJSValue.h M Source/JavaScriptCore/runtime/JSCell.h M Source/JavaScriptCore/runtime/JSDataView.h M Source/JavaScriptCore/runtime/JSGlobalObject.h M Source/JavaScriptCore/runtime/JSGlobalProxy.h M Source/JavaScriptCore/runtime/JSImmutableButterfly.h M Source/JavaScriptCore/runtime/JSInternalFieldObjectImpl.h M Source/JavaScriptCore/runtime/JSObject.h M Source/JavaScriptCore/runtime/JSPropertyNameEnumerator.h M Source/JavaScriptCore/runtime/JSRemoteFunction.h M Source/JavaScriptCore/runtime/JSString.h M Source/JavaScriptCore/runtime/JSSymbolTableObject.h M Source/JavaScriptCore/runtime/JSTypeInfo.h M Source/JavaScriptCore/runtime/JSWrapperObject.h M Source/JavaScriptCore/runtime/MegamorphicCache.h M Source/JavaScriptCore/runtime/NativeExecutable.h M Source/JavaScriptCore/runtime/NumericStrings.h M Source/JavaScriptCore/runtime/RegExpCachedResult.h M Source/JavaScriptCore/runtime/RegExpGlobalData.h M Source/JavaScriptCore/runtime/RegExpObject.h M Source/JavaScriptCore/runtime/ScopedArguments.h M Source/JavaScriptCore/runtime/ScopedArgumentsTable.h M Source/JavaScriptCore/runtime/Structure.h M Source/JavaScriptCore/runtime/StructureRareData.h M Source/JavaScriptCore/runtime/StructureRareDataInlines.h M Source/JavaScriptCore/runtime/Symbol.h M Source/JavaScriptCore/runtime/TypeInfoBlob.h M Source/JavaScriptCore/runtime/TypeProfilerLog.h M Source/JavaScriptCore/runtime/VM.h M Source/JavaScriptCore/runtime/WeakMapImpl.h M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp M Source/JavaScriptCore/wasm/WasmCallee.h M Source/JavaScriptCore/wasm/WasmFormat.h M Source/JavaScriptCore/wasm/WasmGlobal.h M Source/JavaScriptCore/wasm
[webkit-changes] [WebKit/WebKit] 9c096f: exceptions can't always be checked under silent sp...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 9c096feb7d8963e513f0af3320e2d9b7ac4ea393 https://github.com/WebKit/WebKit/commit/9c096feb7d8963e513f0af3320e2d9b7ac4ea393 Author: Keith Miller Date: 2024-05-24 (Fri, 24 May 2024) Changed paths: M JSTests/stress/generator-cell-with-type.js A JSTests/stress/stack-overflow-in-scope-with-catch.js M Source/JavaScriptCore/Scripts/process-entitlements.sh M Source/JavaScriptCore/dfg/DFGArrayifySlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallArrayAllocatorSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGRegisterBank.h M Source/JavaScriptCore/dfg/DFGSaneStringGetByValSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSilentRegisterSavePlan.h M Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.cpp M Source/JavaScriptCore/jit/GPRInfo.h M Source/JavaScriptCore/jit/OperationResult.h M Source/JavaScriptCore/jit/Reg.h M Source/JavaScriptCore/jit/RegisterSet.h Log Message: --- exceptions can't always be checked under silent spill in DFG https://bugs.webkit.org/show_bug.cgi?id=274291 rdar://128067350 Reviewed by Yusuke Suzuki. I originally left a `probeDebug` in the change, which caused perf regressions. This is just removing that debugging logic and relanding. If we're catching an exception in the same DFG frame it's potentially not safe to check for exceptions under a silent spill. This is because the OSR exit ramp does not know about the silent spill. So values will not be restored. There were a couple of possible fixes: 1) teach the DFGVariableEventStream about exceptions under silent spill. 2) add extra metadata about the fact we’re under a silent spill and silent fill before hitting the OSR exit ramp. 3) move the exception to an unused gpr until we can silent fill if needed. I went with option 3. 1. has the problem that it's complicated and might be a memory regression. 2. could bloat code size. I also noticed that my `requires (!OperationHasResult)` checks were not properly eliminating overloads. This is because when you do e.g. `requires (!OperationHasResult)` the `OperationHasResult` will fail SFINAE but that just makes the concept false which then becomes true in the requirement. Instead we now have a new `OperationIsVoid` concept. Canonical link: https://commits.webkit.org/279295@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 53be00: BBQ needs to move stack results from a call to the...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 53be00f7a1fc6ceb136d6b838a100821c99691f0 https://github.com/WebKit/WebKit/commit/53be00f7a1fc6ceb136d6b838a100821c99691f0 Author: Keith Miller Date: 2024-05-25 (Sat, 25 May 2024) Changed paths: A JSTests/wasm/stress/many-calls-results-on-stack.js M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp Log Message: --- BBQ needs to move stack results from a call to their canonical location https://bugs.webkit.org/show_bug.cgi?id=271175 rdar://124060867 Reviewed by Yusuke Suzuki. Right now we can end up clobbering a value, `X`, on the stack in BBQ because it gets left in a `StackArgument` `Location` after a call. This breaks when a later call before `X` has been consumed would set the same `StackArgument` location as `X`. The fix is to just always move stack results to their canonical location. This is probably fine because stack results are super rare in practice. * JSTests/wasm/stress/many-calls-results-on-stack.js: Added. (repeat): (check): (async test): * Source/JavaScriptCore/wasm/WasmBBQJIT.cpp: (JSC::Wasm::BBQJIT::returnValuesFromCall): Originally-landed-as: 272448.770@safari-7618-branch (6d311cd7fefc). rdar://128550307 Canonical link: https://commits.webkit.org/279316@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] e44e4c: SIGTRAP in JIT'ed code
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: e44e4c11207c6381595df8e930cd11c0746aabee https://github.com/WebKit/WebKit/commit/e44e4c11207c6381595df8e930cd11c0746aabee Author: Keith Miller Date: 2024-06-02 (Sun, 02 Jun 2024) Changed paths: A JSTests/stress/regexp-constructor-input-stack-overflow.js M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp Log Message: --- SIGTRAP in JIT'ed code https://bugs.webkit.org/show_bug.cgi?id=275014 rdar://129096982 Reviewed by Yusuke Suzuki. Add a missing exception check to compileCallCustomAccessorSetter I accidentially dropped in 278477@main. * JSTests/stress/regexp-constructor-input-stack-overflow.js: Added. (try.new): (catch): * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp: Canonical link: https://commits.webkit.org/279625@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 5d9f69: Prepare StringImpl for concurrent sweeping
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 5d9f6950a5c46a4d6701c9a12f1c668b2012b3aa https://github.com/WebKit/WebKit/commit/5d9f6950a5c46a4d6701c9a12f1c668b2012b3aa Author: Keith Miller Date: 2024-06-03 (Mon, 03 Jun 2024) Changed paths: M Source/WTF/wtf/Atomics.h M Source/WTF/wtf/text/ExternalStringImpl.cpp M Source/WTF/wtf/text/StringImpl.cpp M Source/WTF/wtf/text/StringImpl.h Log Message: --- Prepare StringImpl for concurrent sweeping https://bugs.webkit.org/show_bug.cgi?id=275036 rdar://129139374 Reviewed by Yusuke Suzuki. This patch adds the parts needed for concurrent sweeping of JSStrings. For CPUs where relaxed atomic ref counting is essetially free this patch makes ref/deref of strings atomic. This enables derefing JSString's underlying StringImpl from the sweeping thread. For other CPUs, it sets up the necessary bits to allow detecting of a String needs deref on the main thread or destruction from the sweeper thread. To make this work StringImpl's m_hashAndFlags is now Atomic. It's mostly write once so the impact should be negligible. It's possible that lazily computing the hash for StaticStrings now would be profitable but this patch doesn't make that change. This patch also adds the implementation of StringImpl::tryDerefConcurrently() which will eventually be used by the concurrent sweeper. * Source/WTF/wtf/Atomics.h: (WTF::NonAtomic::NonAtomic): (WTF::NonAtomic::load const): (WTF::NonAtomic::loadRelaxed const): (WTF::NonAtomic::store): (WTF::NonAtomic::storeRelaxed): (WTF::NonAtomic::exchangeAdd): (WTF::NonAtomic::exchangeSub): (WTF::NonAtomic::exchangeOr): (WTF::NonAtomic::exchangeAnd): * Source/WTF/wtf/text/ExternalStringImpl.cpp: (WTF::ExternalStringImpl::ExternalStringImpl): * Source/WTF/wtf/text/StringImpl.cpp: (WTF::StringImpl::createStaticStringImpl): * Source/WTF/wtf/text/StringImpl.h: (WTF::StringImpl::maskIsUniqued): (WTF::StringImpl::is8Bit const): (WTF::StringImpl::isSymbol const): (WTF::StringImpl::isAtom const): (WTF::StringImpl::isUniqued const): (WTF::StringImpl::rawHash const): (WTF::StringImpl::isStatic const): (WTF::StringImpl::refCount const): (WTF::StringImpl::hasOneRef const): (WTF::StringImpl::hasAtLeastOneRef const): (WTF::StringImpl::bufferOwnership const): (WTF::StringImpl::cost const): (WTF::StringImpl::setIsAtom): (WTF::StringImpl::setHash const): (WTF::StringImpl::ref): (WTF::StringImpl::deref): (WTF::StringImpl::tryDerefConcurrently): Canonical link: https://commits.webkit.org/279650@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 6cca8d: Fix operationCreateThis with exception return regi...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 6cca8d0d598c75029de532aaf5bd93909387fa1d https://github.com/WebKit/WebKit/commit/6cca8d0d598c75029de532aaf5bd93909387fa1d Author: Keith Miller Date: 2024-06-03 (Mon, 03 Jun 2024) Changed paths: M Source/JavaScriptCore/dfg/DFGOperations.cpp M Source/JavaScriptCore/jit/OperationResult.h Log Message: --- Fix operationCreateThis with exception return registers https://bugs.webkit.org/show_bug.cgi?id=275082 rdar://problem/129190985 Reviewed by Yusuke Suzuki. Because of the way we forward exception status to JIT code doesn't play necessarily nicely with DeferTermination at the top level of an operation. This is because the destructor of DeferTermination runs after we've initialized our exception register. While not a semantic issue this breaks tests in RELEASE+ASSERT builds. * Source/JavaScriptCore/dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/jit/OperationResult.h: (JSC::makeOperationResult): Canonical link: https://commits.webkit.org/279682@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] b368bc: Fix operationCreateThis with exception return regi...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b368bc13e2cba3d73a40c37c8ac7a64fe5533803 https://github.com/WebKit/WebKit/commit/b368bc13e2cba3d73a40c37c8ac7a64fe5533803 Author: Keith Miller Date: 2024-06-04 (Tue, 04 Jun 2024) Changed paths: M Source/JavaScriptCore/dfg/DFGOperations.cpp Log Message: --- Fix operationCreateThis with exception return registers https://bugs.webkit.org/show_bug.cgi?id=275082 rdar://problem/129190985 Reviewed by Yusuke Suzuki. Reland without the ASSERT in makeOperationResult because it doesn't play nicely with the inspector's use of SuspendExceptionScope. Because of the way we forward exception status to JIT code doesn't play necessarily nicely with DeferTermination at the top level of an operation. This is because the destructor of DeferTermination runs after we've initialized our exception register. While not a semantic issue this breaks tests in RELEASE+ASSERT builds. * Source/JavaScriptCore/dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): Canonical link: https://commits.webkit.org/279711@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 8c39a7: [JSC] Add Concurrent Sweeping Locking
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 8c39a7f2d80cb15d32d8b1317aa4fa61b33947f2 https://github.com/WebKit/WebKit/commit/8c39a7f2d80cb15d32d8b1317aa4fa61b33947f2 Author: Keith Miller Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M Source/JavaScriptCore/heap/BlockDirectory.cpp M Source/JavaScriptCore/heap/BlockDirectory.h M Source/JavaScriptCore/heap/BlockDirectoryBits.h M Source/JavaScriptCore/heap/BlockDirectoryInlines.h M Source/JavaScriptCore/heap/IncrementalSweeper.cpp M Source/JavaScriptCore/heap/IsoCellSet.cpp M Source/JavaScriptCore/heap/IsoCellSetInlines.h M Source/JavaScriptCore/heap/LocalAllocator.cpp M Source/JavaScriptCore/heap/MarkedBlock.cpp M Source/JavaScriptCore/heap/MarkedBlock.h M Source/JavaScriptCore/heap/MarkedBlockInlines.h M Source/JavaScriptCore/heap/MarkedSpace.cpp M Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp Log Message: --- [JSC] Add Concurrent Sweeping Locking https://bugs.webkit.org/show_bug.cgi?id=275085 rdar://problem/129194601 Reviewed by Yusuke Suzuki. This patch updates the various parts needed for BlockDirectory to work with concurrent sweeping. To make sure the future sweeper thread and the mutator don't clobber each other this patch adds a new bit to BlockDirectory that tracks when a MarkedBlock is "in use". Being in use means that the MarkedBlock is actively being swept or allocated out of. Additionally, we need to make sure that we don't see a tear when updating the BlockDirectory bits. This is done by holding the BlockDirectory's bit vector lock when reading/writing the following bit fields: 1) empty 2) destructable 3) unswept 4) inUse To help make the locking mechanism for BlockDirectoryBits more clear this patch adds support for Clang's thread safety analysis tooling with some special tricks for reading/writing. Specifically, this patch adds assertIsMutatorOrMutatorIsStopped that tells the thread safety analysis m_bitvectorLock is acquired in as a shared lock (despite m_bitvectorLock being an exclusive lock) when reading from m_bits is race-safe. The read-only accessors for m_bits take the "shared" lock so Clang is happy. For cases where writing is race-free there is assertSweeperIsSuspended which "assert acquires" m_bitvectorLock and allows access to the mutating accessors of m_bits. Note, the concurrent sweeper doesn't sweep weak blocks because it's not thread safe to do so. This is ok though because when the main thread goes to allocate out of a marked block it always does another sweep to build the free list, which will clear these weak impls. * Source/JavaScriptCore/heap/BlockDirectory.cpp: (JSC::BlockDirectory::findEmptyBlockToSteal): (JSC::BlockDirectory::findBlockForAllocation): (JSC::BlockDirectory::tryAllocateBlock): (JSC::BlockDirectory::addBlock): (JSC::BlockDirectory::removeBlock): (JSC::BlockDirectory::stopAllocating): (JSC::BlockDirectory::prepareForAllocation): (JSC::BlockDirectory::resumeAllocating): (JSC::BlockDirectory::beginMarkingForFullCollection): (JSC::BlockDirectory::endMarking): (JSC::BlockDirectory::snapshotUnsweptForEdenCollection): (JSC::BlockDirectory::snapshotUnsweptForFullCollection): (JSC::BlockDirectory::findBlockToSweep): (JSC::BlockDirectory::sweep): (JSC::BlockDirectory::shrink): (JSC::BlockDirectory::assertNoUnswept): (JSC::BlockDirectory::didFinishUsingBlock): (JSC::BlockDirectory::parallelNotEmptyBlockSource): (JSC::BlockDirectory::dumpBits): (JSC::BlockDirectory::assertIsMutatorOrMutatorIsStopped): * Source/JavaScriptCore/heap/BlockDirectory.h: (JSC::BlockDirectory::assertSweeperIsSuspended): (JSC::BlockDirectory::assertIsMutatorOrMutatorIsStopped): (JSC::BlockDirectory::WTF_RETURNS_LOCK): (JSC::BlockDirectory::WTF_REQUIRES_LOCK): (JSC::BlockDirectory::WTF_REQUIRES_SHARED_LOCK): (JSC::BlockDirectory::findBlockToSweep): (JSC::BlockDirectory::forEachBitVector): Deleted. (JSC::BlockDirectory::forEachBitVectorWithName): Deleted. * Source/JavaScriptCore/heap/BlockDirectoryBits.h: * Source/JavaScriptCore/heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::sweepNextBlock): * Source/JavaScriptCore/heap/LocalAllocator.cpp: (JSC::LocalAllocator::tryAllocateIn): * Source/JavaScriptCore/heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated): (JSC::MarkedBlock::Handle::stopAllocating): (JSC::MarkedBlock::Handle::lastChanceToFinalize): (JSC::MarkedBlock::Handle::resumeAllocating): (JSC::MarkedBlock::aboutToMarkSlow): (JSC::MarkedBlock::Handle::didConsumeFreeList): (JSC::MarkedBlock::noteMarkedSlow): (JSC::MarkedBlock::Handle::dumpState): (JSC::MarkedBlock::Handle::sweep): * Source/JavaScriptCore/heap/MarkedBlock.h: * Source/JavaScriptCore/heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::isAllocated): (JSC::MarkedBlock::Handle::isLive): (JSC::MarkedBlock::Handle::specializedSweep): (J
[webkit-changes] [WebKit/WebKit] c41cae: HeapIterationScope should require the JS API lock
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c41cae2236b0d5ab176b6aa835f5d6ed58ad193d https://github.com/WebKit/WebKit/commit/c41cae2236b0d5ab176b6aa835f5d6ed58ad193d Author: Keith Miller Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M Source/JavaScriptCore/heap/HeapIterationScope.h M Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp M Source/WebCore/page/PerformanceLogging.cpp Log Message: --- HeapIterationScope should require the JS API lock https://bugs.webkit.org/show_bug.cgi?id=275173 rdar://problem/129294904 Reviewed by Yusuke Suzuki. Right now some users of HeapIterationScope aren't holding the JS API lock. This might be ok but also runs the risk of some other thread running JS at the same time as heap iteration. This patch changes all callers to hold the JS API lock. * Source/JavaScriptCore/heap/HeapIterationScope.h: (JSC::HeapIterationScope::HeapIterationScope): * Source/JavaScriptCore/inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::addSymbolicBreakpoint): * Source/WebCore/page/PerformanceLogging.cpp: Canonical link: https://commits.webkit.org/279749@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ccb2f0: dataLogIf should check the condition is a bool or ...
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ccb2f0d494326452b30f8f40174d5195e60e5e49
https://github.com/WebKit/WebKit/commit/ccb2f0d494326452b30f8f40174d5195e60e5e49
Author: Keith Miller
Date: 2024-06-05 (Wed, 05 Jun 2024)
Changed paths:
M Source/JavaScriptCore/wasm/WasmStreamingParser.cpp
M Source/WTF/wtf/DataLog.h
Log Message:
---
dataLogIf should check the condition is a bool or enum
https://bugs.webkit.org/show_bug.cgi?id=275155
rdar://problem/129280739
Reviewed by Justin Michaud.
I often make the mistake of accidentally writing `dataLogIf("thing I want to
log");`
Which is probably not what people intended. This patch adds some simple
validation
to make that harder.
* Source/JavaScriptCore/wasm/WasmStreamingParser.cpp:
(JSC::Wasm::StreamingParser::StreamingParser):
* Source/WTF/wtf/DataLog.h:
Canonical link: https://commits.webkit.org/279753@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] c56243: REGRESSION(279738@main): ASSERTION FAILED: heap.vm...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c562438ba0b24c7a4300c17390e2104b8fff527b https://github.com/WebKit/WebKit/commit/c562438ba0b24c7a4300c17390e2104b8fff527b Author: Keith Miller Date: 2024-06-05 (Wed, 05 Jun 2024) Changed paths: M Source/JavaScriptCore/debugger/Debugger.cpp Log Message: --- REGRESSION(279738@main): ASSERTION FAILED: heap.vm().currentThreadIsHoldingAPILock() || heap.worldIsStopped() https://bugs.webkit.org/show_bug.cgi?id=275179 rdar://129313337 Unreviewed, one more place needed to hold the API lock. * Source/JavaScriptCore/debugger/Debugger.cpp: (JSC::Debugger::attach): Canonical link: https://commits.webkit.org/279764@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] b6db30: Debug assertions should print the stack trace again
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b6db305ef703967e6727c0120b7e46305b02b008 https://github.com/WebKit/WebKit/commit/b6db305ef703967e6727c0120b7e46305b02b008 Author: Keith Miller Date: 2024-06-06 (Thu, 06 Jun 2024) Changed paths: M Source/WTF/wtf/Assertions.h Log Message: --- Debug assertions should print the stack trace again https://bugs.webkit.org/show_bug.cgi?id=275227 rdar://129365866 Reviewed by Yijia Huang. They used to have backtraces this patch revives that feature. * Source/WTF/wtf/Assertions.h: Canonical link: https://commits.webkit.org/279787@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 58b937: [JSC] Add Concurrent Sweeping Locking
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 58b937859832c12a4df62a2486ee23ccca6a5cb6 https://github.com/WebKit/WebKit/commit/58b937859832c12a4df62a2486ee23ccca6a5cb6 Author: Keith Miller Date: 2024-06-09 (Sun, 09 Jun 2024) Changed paths: M Source/JavaScriptCore/heap/BlockDirectory.cpp M Source/JavaScriptCore/heap/BlockDirectory.h M Source/JavaScriptCore/heap/BlockDirectoryBits.h M Source/JavaScriptCore/heap/BlockDirectoryInlines.h M Source/JavaScriptCore/heap/HeapIterationScope.h M Source/JavaScriptCore/heap/IncrementalSweeper.cpp M Source/JavaScriptCore/heap/IsoCellSet.cpp M Source/JavaScriptCore/heap/IsoCellSetInlines.h M Source/JavaScriptCore/heap/LocalAllocator.cpp M Source/JavaScriptCore/heap/MarkedBlock.cpp M Source/JavaScriptCore/heap/MarkedBlock.h M Source/JavaScriptCore/heap/MarkedBlockInlines.h M Source/JavaScriptCore/heap/MarkedSpace.cpp Log Message: --- [JSC] Add Concurrent Sweeping Locking https://bugs.webkit.org/show_bug.cgi?id=275085 rdar://problem/129194601 Reviewed by Yusuke Suzuki. This patch updates the various parts needed for BlockDirectory to work with concurrent sweeping. To make sure the future sweeper thread and the mutator don't clobber each other this patch adds a new bit to BlockDirectory that tracks when a MarkedBlock is "in use". Being in use means that the MarkedBlock is actively being swept or allocated out of. Additionally, we need to make sure that we don't see a tear when updating the BlockDirectory bits. This is done by holding the BlockDirectory's bit vector lock when reading/writing the following bit fields: 1) empty 2) destructable 3) unswept 4) inUse To help make the locking mechanism for BlockDirectoryBits more clear this patch adds support for Clang's thread safety analysis tooling with some special tricks for reading/writing. Specifically, this patch adds assertIsMutatorOrMutatorIsStopped that tells the thread safety analysis m_bitvectorLock is acquired in as a shared lock (despite m_bitvectorLock being an exclusive lock) when reading from m_bits is race-safe. The read-only accessors for m_bits take the "shared" lock so Clang is happy. For cases where writing is race-free there is assertSweeperIsSuspended which "assert acquires" m_bitvectorLock and allows access to the mutating accessors of m_bits. Note, the concurrent sweeper doesn't sweep weak blocks because it's not thread safe to do so. This is ok though because when the main thread goes to allocate out of a marked block it always does another sweep to build the free list, which will clear these weak impls. Lastly, this patch adds an assertion to HeapIterationScope that the current thread is holding the API lock. It's expected the JS isn't running concurrently to HeapIterationScope so this shouldn't be an issue. * Source/JavaScriptCore/heap/BlockDirectory.cpp: (JSC::BlockDirectory::findEmptyBlockToSteal): (JSC::BlockDirectory::findBlockForAllocation): (JSC::BlockDirectory::tryAllocateBlock): (JSC::BlockDirectory::addBlock): (JSC::BlockDirectory::removeBlock): (JSC::BlockDirectory::stopAllocating): (JSC::BlockDirectory::prepareForAllocation): (JSC::BlockDirectory::stopAllocatingForGood): (JSC::BlockDirectory::resumeAllocating): (JSC::BlockDirectory::beginMarkingForFullCollection): (JSC::BlockDirectory::endMarking): (JSC::BlockDirectory::snapshotUnsweptForEdenCollection): (JSC::BlockDirectory::snapshotUnsweptForFullCollection): (JSC::BlockDirectory::findBlockToSweep): (JSC::BlockDirectory::sweep): (JSC::BlockDirectory::shrink): (JSC::BlockDirectory::assertNoUnswept): (JSC::BlockDirectory::didFinishUsingBlock): (JSC::BlockDirectory::parallelNotEmptyBlockSource): (JSC::BlockDirectory::dumpBits): (JSC::BlockDirectory::assertIsMutatorOrMutatorIsStopped const): (JSC::BlockDirectory::assertSweeperIsSuspended const): * Source/JavaScriptCore/heap/BlockDirectory.h: (JSC::BlockDirectory::WTF_ASSERTS_ACQUIRED_SHARED_LOCK): (JSC::BlockDirectory::WTF_ASSERTS_ACQUIRED_LOCK): (JSC::BlockDirectory::WTF_REQUIRES_LOCK): (JSC::BlockDirectory::WTF_REQUIRES_SHARED_LOCK): (JSC::BlockDirectory::findBlockToSweep): (JSC::BlockDirectory::forEachBitVector): Deleted. (JSC::BlockDirectory::forEachBitVectorWithName): Deleted. * Source/JavaScriptCore/heap/BlockDirectoryBits.h: * Source/JavaScriptCore/heap/BlockDirectoryInlines.h: (JSC::BlockDirectory::forEachBlock): (JSC::BlockDirectory::forEachNotEmptyBlock): * Source/JavaScriptCore/heap/HeapIterationScope.h: (JSC::HeapIterationScope::HeapIterationScope): * Source/JavaScriptCore/heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::sweepNextBlock): * Source/JavaScriptCore/heap/IsoCellSet.cpp: (JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource): * Source/JavaScriptCore/heap/IsoCellSetInlines.h: (JSC::IsoCellSet::forEachMarkedCell): * Source/JavaScriptCore/heap/LocalAlloca
webkit-changes@lists.webkit.org
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 89d69b59b62aa4ca20e50614efff5e1c34269291 https://github.com/WebKit/WebKit/commit/89d69b59b62aa4ca20e50614efff5e1c34269291 Author: Keith Miller Date: 2024-06-11 (Tue, 11 Jun 2024) Changed paths: M Source/JavaScriptCore/heap/Heap.cpp Log Message: --- ASSERTION FAILED: owner->get() == &Thread::current() in JSC::BlockDirectory::assertIsMutatorOrMutatorIsStopped for inspector/memory/tracking.html https://bugs.webkit.org/show_bug.cgi?id=275351 rdar://problem/129580672 Reviewed by Yusuke Suzuki. The assert in of `m_objectSpace.capacity() >= m_objectSpace.size()` in `Heap::extraMemorySize()` is invalid as calling `m_objectSpace.size()` requires being the mutator currently, which `WebCore::ResourceUsageThread` is not. * Source/JavaScriptCore/heap/Heap.cpp: (JSC::Heap::extraMemorySize): Canonical link: https://commits.webkit.org/279920@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 7c0d59: Prepare StringImpl for concurrent sweeping
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 7c0d5979a6587fa13e06e093df7cd8be6bb7b4fd https://github.com/WebKit/WebKit/commit/7c0d5979a6587fa13e06e093df7cd8be6bb7b4fd Author: Keith Miller Date: 2024-06-15 (Sat, 15 Jun 2024) Changed paths: M Source/WTF/wtf/Atomics.h M Source/WTF/wtf/text/ExternalStringImpl.cpp M Source/WTF/wtf/text/StringImpl.cpp M Source/WTF/wtf/text/StringImpl.h Log Message: --- Prepare StringImpl for concurrent sweeping https://bugs.webkit.org/show_bug.cgi?id=275036 rdar://129139374 Reviewed by Yusuke Suzuki. This patch adds the parts needed for concurrent sweeping of JSStrings. For CPUs where relaxed atomic ref counting is essetially free this patch makes ref/deref of strings atomic. This enables derefing JSString's underlying StringImpl from the sweeping thread. For other CPUs, it sets up the necessary bits to allow detecting of a String needs deref on the main thread or destruction from the sweeper thread. To make this work StringImpl's m_hashAndFlags is now Atomic. It's mostly write once so the impact should be negligible. It's possible that lazily computing the hash for StaticStrings now would be profitable but this patch doesn't make that change. This patch also adds the implementation of StringImpl::tryDerefConcurrently() which will eventually be used by the concurrent sweeper. * Source/WTF/wtf/Atomics.h: (WTF::NonAtomic::NonAtomic): (WTF::NonAtomic::load const): (WTF::NonAtomic::loadRelaxed const): (WTF::NonAtomic::store): (WTF::NonAtomic::storeRelaxed): (WTF::NonAtomic::exchangeAdd): (WTF::NonAtomic::exchangeSub): (WTF::NonAtomic::exchangeOr): (WTF::NonAtomic::exchangeAnd): * Source/WTF/wtf/text/ExternalStringImpl.cpp: (WTF::ExternalStringImpl::ExternalStringImpl): * Source/WTF/wtf/text/StringImpl.cpp: (WTF::StringImpl::createStaticStringImpl): * Source/WTF/wtf/text/StringImpl.h: (WTF::StringImpl::maskIsUniqued): (WTF::StringImpl::is8Bit const): (WTF::StringImpl::isSymbol const): (WTF::StringImpl::isAtom const): (WTF::StringImpl::isUniqued const): (WTF::StringImpl::rawHash const): (WTF::StringImpl::isStatic const): (WTF::StringImpl::refCount const): (WTF::StringImpl::hasOneRef const): (WTF::StringImpl::hasAtLeastOneRef const): (WTF::StringImpl::bufferOwnership const): (WTF::StringImpl::cost const): (WTF::StringImpl::setIsAtom): (WTF::StringImpl::setHash const): (WTF::StringImpl::ref): (WTF::StringImpl::deref): (WTF::StringImpl::tryDerefConcurrently): Canonical link: https://commits.webkit.org/280050@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ebb3d2: Remove JSEntrypointJITCallee
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: ebb3d2de4c4bc1b2dd2158d0f96c7c45ba0c1d75 https://github.com/WebKit/WebKit/commit/ebb3d2de4c4bc1b2dd2158d0f96c7c45ba0c1d75 Author: Keith Miller Date: 2024-09-13 (Fri, 13 Sep 2024) Changed paths: M Source/JavaScriptCore/llint/WebAssembly.asm M Source/JavaScriptCore/runtime/SamplingProfiler.cpp M Source/JavaScriptCore/wasm/WasmBBQPlan.cpp M Source/JavaScriptCore/wasm/WasmBBQPlan.h M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmCallee.h M Source/JavaScriptCore/wasm/WasmCalleeGroup.h M Source/JavaScriptCore/wasm/WasmCompilationMode.h M Source/JavaScriptCore/wasm/WasmIPIntPlan.cpp M Source/JavaScriptCore/wasm/WasmLLIntPlan.cpp M Source/JavaScriptCore/wasm/WasmOMGPlan.cpp M Source/JavaScriptCore/wasm/WasmOMGPlan.h M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmTypeDefinition.h M Source/JavaScriptCore/wasm/js/JSToWasm.cpp M Source/JavaScriptCore/wasm/js/JSToWasm.h M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.h Log Message: --- Remove JSEntrypointJITCallee https://bugs.webkit.org/show_bug.cgi?id=279674 rdar://135952475 Reviewed by Yusuke Suzuki. Now that we have the interpreted entrypoints and JIT IC handlers we no longer need the legacy wasm entrypoints. This patch removes the old entrypoint and merges JITLessJSEntrypointCallee into JSEntrypointCallee. To make this work the higher tiers also now replace the previous call target with the one they just compiled. * Source/JavaScriptCore/llint/WebAssembly.asm: * Source/JavaScriptCore/runtime/SamplingProfiler.cpp: (JSC::tierName): * Source/JavaScriptCore/wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): (JSC::Wasm::BBQPlan::compileFunction): (JSC::Wasm::BBQPlan::didCompleteCompilation): (JSC::Wasm::BBQPlan::initializeCallees): * Source/JavaScriptCore/wasm/WasmBBQPlan.h: * Source/JavaScriptCore/wasm/WasmCallee.cpp: (JSC::Wasm::Callee::runWithDowncast): (JSC::Wasm::JSEntrypointCallee::JSEntrypointCallee): (JSC::Wasm::JSEntrypointJITCallee::setEntrypoint): Deleted. (JSC::Wasm::JITLessJSEntrypointCallee::JITLessJSEntrypointCallee): Deleted. * Source/JavaScriptCore/wasm/WasmCallee.h: (JSC::Wasm::JSEntrypointCallee::create): (JSC::Wasm::JSEntrypointCallee::setReplacementTarget): (JSC::Wasm::JSEntrypointCallee::offsetOfIdent): (JSC::Wasm::JSEntrypointCallee::offsetOfWasmCallee): (JSC::Wasm::JSEntrypointCallee::offsetOfWasmFunctionPrologue): (JSC::Wasm::JSEntrypointCallee::offsetOfFrameSize): (JSC::Wasm::JSEntrypointCallee::JSEntrypointCallee): Deleted. * Source/JavaScriptCore/wasm/WasmCalleeGroup.h: * Source/JavaScriptCore/wasm/WasmCompilationMode.h: (JSC::Wasm::isOSREntry): (JSC::Wasm::isAnyBBQ): (JSC::Wasm::isAnyOMG): * Source/JavaScriptCore/wasm/WasmIPIntPlan.cpp: (JSC::Wasm::IPIntPlan::ensureEntrypoint): * Source/JavaScriptCore/wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::ensureEntrypoint): (JSC::Wasm::LLIntPlan::didCompleteCompilation): * Source/JavaScriptCore/wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * Source/JavaScriptCore/wasm/WasmOMGPlan.h: * Source/JavaScriptCore/wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION): (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/wasm/WasmTypeDefinition.h: * Source/JavaScriptCore/wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmJITShared): (JSC::Wasm::createJSToWasmWrapper): Deleted. * Source/JavaScriptCore/wasm/js/JSToWasm.h: * Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp: (JSC::m_jsToWasmCallee): Deleted. * Source/JavaScriptCore/wasm/js/WebAssemblyFunction.h: Canonical link: https://commits.webkit.org/283638@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 997e07: Add support for Error.captureStackTrace
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 997e074bb35ed07b69c9b821141c91dd548e0d02 https://github.com/WebKit/WebKit/commit/997e074bb35ed07b69c9b821141c91dd548e0d02 Author: Keith Miller Date: 2023-08-17 (Thu, 17 Aug 2023) Changed paths: A JSTests/stress/captureStackTrace-on-error-object.js A JSTests/stress/captureStackTrace.js M LayoutTests/js/Object-getOwnPropertyNames-expected.txt M LayoutTests/js/script-tests/Object-getOwnPropertyNames.js M Source/JavaScriptCore/interpreter/Interpreter.cpp M Source/JavaScriptCore/interpreter/Interpreter.h M Source/JavaScriptCore/runtime/CommonIdentifiers.h M Source/JavaScriptCore/runtime/Error.cpp M Source/JavaScriptCore/runtime/ErrorConstructor.cpp Log Message: --- Add support for Error.captureStackTrace https://bugs.webkit.org/show_bug.cgi?id=260326 rdar://113767788 Reviewed by Yusuke Suzuki. This change adds support for the Error.captureStackTrace extension. We mostly want it because web tooling benchamrk uses it in the hot path of the chai-wtb test, where having native Error.captureStackTrace is a 5% progression over the polyfill. Error.captureStackTrace(obj[, caller]) sets the "stack" property on obj with a string of the current callstack. If caller is provided then any frames above (textually, below in the machine stack) or at the first reference to caller are omitted from the trace. Our implementation should behave the same as v8's with two exceptions: 1) The stack trace is formatted the same as our Error.stack, not v8's. 2) v8 makes the stack property a getter/setter whereas we make it a data property, like our Error object. * Source/JavaScriptCore/interpreter/Interpreter.cpp: (JSC::Interpreter::getStackTrace): * Source/JavaScriptCore/interpreter/Interpreter.h: * Source/JavaScriptCore/runtime/CommonIdentifiers.h: * Source/JavaScriptCore/runtime/Error.cpp: (JSC::getStackTrace): * Source/JavaScriptCore/runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): Canonical link: https://commits.webkit.org/267010@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] c55d06: Could round rather than truncate in compileClampDo...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c55d0673236c1b2367cc0f820298c06d4967346d https://github.com/WebKit/WebKit/commit/c55d0673236c1b2367cc0f820298c06d4967346d Author: Keith Miller Date: 2023-08-21 (Mon, 21 Aug 2023) Changed paths: A JSTests/stress/uint8clamped-rounding-mode.js M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp Log Message: --- Could round rather than truncate in compileClampDoubleToByte? https://bugs.webkit.org/show_bug.cgi?id=72054 rdar://113734964 Reviewed by Yusuke Suzuki. Right now there's a difference between our non-optimizing code and our C++ code for ClampedUint8Arrays. In the C++ code we correctly do a round to nearest (ties to even) but in the optimizing JITs we do a round to inifinity. This patch fixes our optimizing code to round to nearest too. * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::clampDoubleToByte): (JSC::DFG::compileClampDoubleToByte): * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): Canonical link: https://commits.webkit.org/267100@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 41169e: Colocate ValueProfiles
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 41169e7edae194d93e7c21bbd76b285d6128fa55 https://github.com/WebKit/WebKit/commit/41169e7edae194d93e7c21bbd76b285d6128fa55 Author: Keith Miller Date: 2023-09-05 (Tue, 05 Sep 2023) Changed paths: M JSTests/wasm/stress/simple-inline-stacktrace.js M LayoutTests/js/script-tests/regress-139548.js M Source/JavaScriptCore/bytecode/BytecodeGeneratorification.cpp M Source/JavaScriptCore/bytecode/BytecodeList.rb M Source/JavaScriptCore/bytecode/BytecodeOperandsForCheckpoint.h M Source/JavaScriptCore/bytecode/CodeBlock.cpp M Source/JavaScriptCore/bytecode/CodeBlock.h M Source/JavaScriptCore/bytecode/CodeBlockInlines.h M Source/JavaScriptCore/bytecode/MetadataTable.cpp M Source/JavaScriptCore/bytecode/MetadataTable.h M Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp M Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h M Source/JavaScriptCore/bytecode/UnlinkedCodeBlockGenerator.cpp M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h M Source/JavaScriptCore/bytecode/UnlinkedMetadataTableInlines.h M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h M Source/JavaScriptCore/jit/JITInlines.h M Source/JavaScriptCore/jit/JITPropertyAccess.cpp M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm M Source/JavaScriptCore/runtime/CachedTypes.cpp M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp Log Message: --- Colocate ValueProfiles https://bugs.webkit.org/show_bug.cgi?id=261151 rdar://114387937 Reviewed by Yusuke Suzuki. We spend a lot of time in updateAllNonLazyValueProfilePredictions during our benchmark runs. In order to improve the throughput of that function we should move all ValueProfiles into their own buffer. This improves the memory locality of ValueProfiles. From my testing this is ~.5% progression on Speedometer2/3 and JetStream2. In order to not need a new register for ValueProfiles in the LLInt/Baseline we "butterfly" the MetadataTable so that negative indicies point to ValueProfiles and positive indicies point to the old MetadataTable contents. * Source/JavaScriptCore/bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::run): * Source/JavaScriptCore/bytecode/BytecodeList.rb: * Source/JavaScriptCore/bytecode/BytecodeOperandsForCheckpoint.h: (JSC::valueProfileOffsetFor): (JSC::valueProfileForImpl): Deleted. (JSC::hasValueProfileFor): Deleted. (JSC::valueProfileFor): Deleted. * Source/JavaScriptCore/bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::estimatedSize): (JSC::CodeBlock::visitChildren): (JSC::CodeBlock::tryGetValueProfileForBytecodeIndex): * Source/JavaScriptCore/bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfileForOffset): * Source/JavaScriptCore/bytecode/CodeBlockInlines.h: (JSC::CodeBlock::forEachValueProfile): * Source/JavaScriptCore/bytecode/MetadataTable.cpp: (JSC::MetadataTable::sizeInBytesForGC): (JSC::MetadataTable::sizeInBytes): Deleted. * Source/JavaScriptCore/bytecode/MetadataTable.h: (JSC::MetadataTable::forEachValueProfile): (JSC::MetadataTable::valueProfilesEnd): (JSC::MetadataTable::valueProfileForOffset): (JSC::MetadataTable::totalSize const): (JSC::MetadataTable::buffer): * Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::visitChildrenImpl): (JSC::UnlinkedCodeBlock::estimatedSize): (JSC::UnlinkedCodeBlock::allocateSharedProfiles): * Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::metadataSizeInBytes): * Source/JavaScriptCore/bytecode/UnlinkedCodeBlockGenerator.cpp: (JSC::UnlinkedCodeBlockGenerator::finalize): * Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp: (JSC::UnlinkedMetadataTable::finalize): * Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h: (JSC::UnlinkedMetadataTable::numValueProfiles const): (JSC::UnlinkedMetadataTable::create): (JSC::UnlinkedMetadataTable::totalSize const): (JSC::UnlinkedMetadataTable::buffer const): (JSC::UnlinkedMetadataTable::preprocessBuffer const): (JSC::UnlinkedMetadataTable::offsetTable16 const): (JSC::UnlinkedMetadataTable::offsetTable32 const): * Source/JavaScriptCore/bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::addValueProfile): (JSC::UnlinkedMetadataTable::sizeInBytesForGC): (JSC::UnlinkedMetadataTable::link): (JSC::UnlinkedMetadataTable::unlink): (JSC::UnlinkedMetadataTable::sizeInBytes): Deleted. * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::Bytecod
[webkit-changes] [WebKit/WebKit] 3a1c34: Add taintedness tracking to JSC
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 3a1c346c2fdeb2cfa85ea094208e38b3cf786149 https://github.com/WebKit/WebKit/commit/3a1c346c2fdeb2cfa85ea094208e38b3cf786149 Author: Keith Miller Date: 2023-09-07 (Thu, 07 Sep 2023) Changed paths: A JSTests/stress/taintedness-tracking-inlining.js A JSTests/stress/taintedness-tracking.js A LayoutTests/js/taintedness-innerhtml-expected.txt A LayoutTests/js/taintedness-innerhtml.html A LayoutTests/js/taintedness-settimeout-expected.txt A LayoutTests/js/taintedness-settimeout.html M Source/JavaScriptCore/API/JSBase.cpp M Source/JavaScriptCore/API/JSObjectRef.cpp M Source/JavaScriptCore/API/JSScript.mm M Source/JavaScriptCore/API/JSScriptRef.cpp M Source/JavaScriptCore/API/glib/JSCContext.cpp M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Scripts/wkbuiltins/builtins_templates.py M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/builtins/BuiltinExecutables.cpp M Source/JavaScriptCore/bytecode/CodeBlock.cpp M Source/JavaScriptCore/bytecode/CodeBlock.h M Source/JavaScriptCore/debugger/DebuggerCallFrame.cpp M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp M Source/JavaScriptCore/dfg/DFGJITCompiler.cpp M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp M Source/JavaScriptCore/inspector/InjectedScriptManager.cpp M Source/JavaScriptCore/inspector/JSInjectedScriptHost.cpp M Source/JavaScriptCore/inspector/agents/InspectorRuntimeAgent.cpp M Source/JavaScriptCore/interpreter/Interpreter.cpp M Source/JavaScriptCore/interpreter/Interpreter.h M Source/JavaScriptCore/jit/JITOpcodes.cpp M Source/JavaScriptCore/jsc.cpp M Source/JavaScriptCore/parser/SourceCode.h M Source/JavaScriptCore/parser/SourceProvider.cpp M Source/JavaScriptCore/parser/SourceProvider.h A Source/JavaScriptCore/parser/SourceTaintedOrigin.cpp A Source/JavaScriptCore/parser/SourceTaintedOrigin.h M Source/JavaScriptCore/runtime/CachedTypes.cpp M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp M Source/JavaScriptCore/runtime/Forward.h M Source/JavaScriptCore/runtime/FunctionConstructor.cpp M Source/JavaScriptCore/runtime/FunctionConstructor.h M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp M Source/JavaScriptCore/runtime/ShadowRealmPrototype.cpp M Source/JavaScriptCore/runtime/VM.h M Source/JavaScriptCore/tools/FunctionOverrides.cpp M Source/JavaScriptCore/tools/JSDollarVM.cpp M Source/WebCore/bindings/js/CachedScriptSourceProvider.h M Source/WebCore/bindings/js/JSLazyEventListener.cpp M Source/WebCore/bindings/js/JSLazyEventListener.h M Source/WebCore/bindings/js/RunJavaScriptParameters.h M Source/WebCore/bindings/js/ScheduledAction.cpp M Source/WebCore/bindings/js/ScheduledAction.h M Source/WebCore/bindings/js/ScriptBufferSourceProvider.h M Source/WebCore/bindings/js/ScriptController.cpp M Source/WebCore/bindings/js/ScriptController.h M Source/WebCore/bindings/js/ScriptSourceCode.h M Source/WebCore/bridge/objc/WebScriptObject.mm M Source/WebCore/contentextensions/ContentExtensionsBackend.cpp M Source/WebCore/css/DOMCSSPaintWorklet.cpp M Source/WebCore/dom/Document.cpp M Source/WebCore/dom/ScriptElement.cpp M Source/WebCore/dom/ScriptElement.h M Source/WebCore/html/HTMLMediaElement.cpp M Source/WebCore/html/parser/HTMLScriptRunner.cpp M Source/WebCore/inspector/InspectorFrontendAPIDispatcher.cpp M Source/WebCore/inspector/InspectorFrontendHost.cpp M Source/WebCore/inspector/agents/InspectorPageAgent.cpp M Source/WebCore/loader/DocumentLoader.cpp M Source/WebCore/page/LocalFrame.cpp M Source/WebCore/testing/Internals.cpp M Source/WebCore/xml/XMLTreeViewer.cpp M Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp M Source/WebKit/DerivedSources-output.xcfilelist M Source/WebKit/UIProcess/API/C/WKPage.cpp M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp M Source/WebKit/UIProcess/Inspector/socket/RemoteInspectorProtocolHandler.cpp M Source/WebKitLegacy/mac/WebView/WebFrame.mm M Source/WebKitLegacy/mac/WebView/WebView.mm Log Message: --- Add taintedness tracking to JSC https://bugs.webkit.org/show_bug.cgi?id=242537 rdar://83222586 Reviewed by Yusuke Suzuki. This patch adds the core structure of what's needed to do taintedness tracking in JSC. This allows us to track tainted code even through eval assuming there isn't support from untainted code. In order to maintain performance of untainted code we add a bit to the VM which tells us if tainted code has run this event loop turn. This allows checkers of taintedness to skip a stack walk in the common case where there's no taint
[webkit-changes] [WebKit/WebKit] a5637e: Add atomics to IPInt
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: a5637e2156cb073b5fb5c820ad02b9115c88e4d7 https://github.com/WebKit/WebKit/commit/a5637e2156cb073b5fb5c820ad02b9115c88e4d7 Author: Keith Miller Date: 2023-09-21 (Thu, 21 Sep 2023) Changed paths: M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/llint/InPlaceInterpreter.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.h M Source/JavaScriptCore/runtime/OptionsList.h M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.cpp M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp M Source/JavaScriptCore/wasm/WasmOperationsInlines.h M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmSlowPaths.h Log Message: --- Add atomics to IPInt https://bugs.webkit.org/show_bug.cgi?id=261855 Reviewed by Yusuke Suzuki. Add support for the wasm thread proposal's atomic instructions to IPInt. Right now this only works for arm64(e) as the IPInt seems to have other issues when running on X86_64. Although the structure of the atomic instructions should be implemented for X86_64. A lot of the instructions were implemented in the LLInt so they could be "straightforwardly" copied to the IPInt. The LLInt seems to do a decent amount of extra work that doesn't seem to be necessary (at least on ARM64E). For example, LLInt ands the low bits of the atomic RMW result even though the instructions zero extend anyway. Additionally, this patch fixes trapping from wasm. Previously, the callee save registers were not saved in the same order that the C++ code expects (in decreasing order). This was fine for IPInt code but broke when doing `genericUnwind`. Lastly, this patch adds an FunctionIPIntMetadataGenerator::addLength for wasm bytecodes that have variable length but no metatdata. This is currently only the extended opcodes since the extended instruction is encoded as a varUInt32 and can be non-canonically encoded as something longer than 1 byte. I believe the other extended bytecodes are incorrect but I will fix those in a follow up patch. * Source/JavaScriptCore/llint/InPlaceInterpreter.asm: * Source/JavaScriptCore/llint/InPlaceInterpreter.cpp: (JSC::IPInt::initialize): * Source/JavaScriptCore/llint/InPlaceInterpreter.h: * Source/JavaScriptCore/runtime/OptionsList.h: * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.cpp: (JSC::Wasm::FunctionIPIntMetadataGenerator::addLength): * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h: * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntGenerator::atomicLoad): (JSC::Wasm::IPIntGenerator::atomicStore): (JSC::Wasm::IPIntGenerator::atomicBinaryRMW): (JSC::Wasm::IPIntGenerator::atomicCompareExchange): (JSC::Wasm::IPIntGenerator::atomicWait): (JSC::Wasm::IPIntGenerator::atomicNotify): (JSC::Wasm::IPIntGenerator::atomicFence): * Source/JavaScriptCore/wasm/WasmOperationsInlines.h: (JSC::Wasm::memoryAtomicWait32): (JSC::Wasm::memoryAtomicWait64): * Source/JavaScriptCore/wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_IPINT_EXTERN_CPP_DECL): * Source/JavaScriptCore/wasm/WasmSlowPaths.h: Canonical link: https://commits.webkit.org/268252@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] e960cd: Cherry-pick 265870.333@safari-7616.1.27.10-branch ...
Branch: refs/heads/webkitglib/2.42 Home: https://github.com/WebKit/WebKit Commit: e960cdca544708c5eb699635438bf5e73c977c51 https://github.com/WebKit/WebKit/commit/e960cdca544708c5eb699635438bf5e73c977c51 Author: Keith Miller Date: 2023-09-21 (Thu, 21 Sep 2023) Changed paths: A JSTests/stress/getbyoffset-cse-consistency.js A JSTests/stress/multigetbyoffset-cse-consistency.js M Source/JavaScriptCore/dfg/DFGCSEPhase.cpp M Source/JavaScriptCore/dfg/DFGClobberize.h M Source/JavaScriptCore/dfg/DFGHeapLocation.h Log Message: --- Cherry-pick 265870.333@safari-7616.1.27.10-branch (ab5c6119c469). https://bugs.webkit.org/show_bug.cgi?id=261544 Cherry-pick 47e039ffd689. rdar://115399657 clobberize needs to be more precise with the *ByOffset nodes https://bugs.webkit.org/show_bug.cgi?id=261544 rdar://115399657 Reviewed by Yusuke Suzuki and Mark Lam. CSE phase uses clobberize to figure out if it's safe to merge two operations that def the same HeapLocation. Since HeapLocation does not currently have a way to track the offset used by the various *ByOffset nodes it can get confused and think that two ByOffset instructions produce the same value even if they don't use the same offset. This patch solves this by adding a new field to HeapLocation, which takes the metadata associated with the corresponding *ByOffset node. If two *ByOffset operations don't share the same metadata then they cannot be CSEed. * Source/JavaScriptCore/dfg/DFGCSEPhase.cpp: * Source/JavaScriptCore/dfg/DFGClobberize.h: (JSC::DFG::clobberize): * Source/JavaScriptCore/dfg/DFGHeapLocation.h: (JSC::DFG::HeapLocation::HeapLocation): (JSC::DFG::HeapLocation::extraState const): (JSC::DFG::HeapLocation::hash const): Canonical link: https://commits.webkit.org/265870.558@safari-7616-branch Identifier: 265423.780@safari-7616.1.27.10-branch ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 370d7a: IPInt should decode LEB for extended opcodes
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 370d7ae576389f08b9d9e4ae477c35dff89e4d08 https://github.com/WebKit/WebKit/commit/370d7ae576389f08b9d9e4ae477c35dff89e4d08 Author: Keith Miller Date: 2023-09-21 (Thu, 21 Sep 2023) Changed paths: A JSTests/wasm/stress/non-canonical-extended-ops.js M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/wasm/WasmFunctionParser.h M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp Log Message: --- IPInt should decode LEB for extended opcodes https://bugs.webkit.org/show_bug.cgi?id=261894 Reviewed by Yusuke Suzuki. Right now it assumes they are 1 byte, which 99.9% of the time they will be. It's technically correct, however, to non-canonically encode them as more than one byte. This patch adds a simple LEB UInt32 decoder to IPInt and uses it to decode the extended opcode. * JSTests/wasm/stress/non-canonical-extended-ops.js: Added. (instance): * Source/JavaScriptCore/llint/InPlaceInterpreter.asm: * Source/JavaScriptCore/wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::truncSaturated): * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntGenerator::addMemoryFill): (JSC::Wasm::IPIntGenerator::addMemoryCopy): (JSC::Wasm::IPIntGenerator::truncSaturated): Canonical link: https://commits.webkit.org/268300@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 22ec86: Unreviewed, revert IPInt Atomics (breaks iOS)
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 22ec864d5e7875428a4459a67f9c387c8b19374b https://github.com/WebKit/WebKit/commit/22ec864d5e7875428a4459a67f9c387c8b19374b Author: Keith Miller Date: 2023-09-22 (Fri, 22 Sep 2023) Changed paths: R JSTests/wasm/stress/non-canonical-extended-ops.js M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/llint/InPlaceInterpreter.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.h M Source/JavaScriptCore/runtime/OptionsList.h M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.cpp M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h M Source/JavaScriptCore/wasm/WasmFunctionParser.h M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp M Source/JavaScriptCore/wasm/WasmOperationsInlines.h M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmSlowPaths.h Log Message: --- Unreviewed, revert IPInt Atomics (breaks iOS) * JSTests/wasm/stress/non-canonical-extended-ops.js: Removed. * Source/JavaScriptCore/llint/InPlaceInterpreter.asm: * Source/JavaScriptCore/llint/InPlaceInterpreter.cpp: (JSC::IPInt::initialize): * Source/JavaScriptCore/llint/InPlaceInterpreter.h: * Source/JavaScriptCore/runtime/OptionsList.h: * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.cpp: (JSC::Wasm::FunctionIPIntMetadataGenerator::addLength): Deleted. * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h: * Source/JavaScriptCore/wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::truncSaturated): * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntGenerator::addMemoryFill): (JSC::Wasm::IPIntGenerator::addMemoryCopy): (JSC::Wasm::IPIntGenerator::atomicLoad): (JSC::Wasm::IPIntGenerator::atomicStore): (JSC::Wasm::IPIntGenerator::atomicBinaryRMW): (JSC::Wasm::IPIntGenerator::atomicCompareExchange): (JSC::Wasm::IPIntGenerator::atomicWait): (JSC::Wasm::IPIntGenerator::atomicNotify): (JSC::Wasm::IPIntGenerator::atomicFence): (JSC::Wasm::IPIntGenerator::truncSaturated): * Source/JavaScriptCore/wasm/WasmOperationsInlines.h: (JSC::Wasm::memoryAtomicWait32): (JSC::Wasm::memoryAtomicWait64): * Source/JavaScriptCore/wasm/WasmSlowPaths.cpp: * Source/JavaScriptCore/wasm/WasmSlowPaths.h: Canonical link: https://commits.webkit.org/268332@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 9a3d98: Reland Atomics in IPInt
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 9a3d986518bcc657eebf7f246604f4b0be78a79e https://github.com/WebKit/WebKit/commit/9a3d986518bcc657eebf7f246604f4b0be78a79e Author: Keith Miller Date: 2023-09-26 (Tue, 26 Sep 2023) Changed paths: A JSTests/wasm/stress/non-canonical-extended-ops.js M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/llint/InPlaceInterpreter.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.h M Source/JavaScriptCore/runtime/OptionsList.h M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.cpp M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h M Source/JavaScriptCore/wasm/WasmFunctionParser.h M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp M Source/JavaScriptCore/wasm/WasmOperationsInlines.h M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmSlowPaths.h Log Message: --- Reland Atomics in IPInt https://bugs.webkit.org/show_bug.cgi?id=262118 Reviewed by Yusuke Suzuki. This is a fixed patch for 268300@main and 268252@main. Before there was an issue that we were using the `unimplementedInstruction` macro instead of the `reservedOpcode` macro for the holes in the Atomic instruction set. The `unimplementedInstruction` macro emits a global label, which on iOS would get stripped. I think this is happening as the definition of the label is not in the same translation unit as the declaration, which has the attribute, so the attribute doesn't get merged into the definition. Right now it seems the only thing preserving the IPInt labels is the `IPInt::initialize()` function and that function did not have any references to the Atomic intruction gaps. * JSTests/wasm/stress/non-canonical-extended-ops.js: Added. (instance): * Source/JavaScriptCore/llint/InPlaceInterpreter.asm: * Source/JavaScriptCore/llint/InPlaceInterpreter.cpp: (JSC::IPInt::initialize): * Source/JavaScriptCore/llint/InPlaceInterpreter.h: * Source/JavaScriptCore/runtime/OptionsList.h: * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.cpp: (JSC::Wasm::FunctionIPIntMetadataGenerator::addLength): * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h: * Source/JavaScriptCore/wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::truncSaturated): * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntGenerator::addMemoryFill): (JSC::Wasm::IPIntGenerator::addMemoryCopy): (JSC::Wasm::IPIntGenerator::atomicLoad): (JSC::Wasm::IPIntGenerator::atomicStore): (JSC::Wasm::IPIntGenerator::atomicBinaryRMW): (JSC::Wasm::IPIntGenerator::atomicCompareExchange): (JSC::Wasm::IPIntGenerator::atomicWait): (JSC::Wasm::IPIntGenerator::atomicNotify): (JSC::Wasm::IPIntGenerator::atomicFence): (JSC::Wasm::IPIntGenerator::truncSaturated): * Source/JavaScriptCore/wasm/WasmOperationsInlines.h: (JSC::Wasm::memoryAtomicWait32): (JSC::Wasm::memoryAtomicWait64): * Source/JavaScriptCore/wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_IPINT_EXTERN_CPP_DECL): * Source/JavaScriptCore/wasm/WasmSlowPaths.h: Canonical link: https://commits.webkit.org/268469@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ba27ec: Versioning.
Branch: refs/heads/safari-7616.1.27.211-branch Home: https://github.com/WebKit/WebKit Commit: ba27ec33b5e22b51ff423d4de0e83efd74fcd47a https://github.com/WebKit/WebKit/commit/ba27ec33b5e22b51ff423d4de0e83efd74fcd47a Author: Dan Robson Date: 2023-08-18 (Fri, 18 Aug 2023) Changed paths: M Configurations/Version.xcconfig Log Message: --- Versioning. WebKit-7616.1.27.111.16 Identifier: 265870.343@safari-7616.1.27.111-branch Commit: a4bb3596d60a871abb78b0347ac0f6433b3a835e https://github.com/WebKit/WebKit/commit/a4bb3596d60a871abb78b0347ac0f6433b3a835e Author: Yusuke Suzuki Date: 2023-08-18 (Fri, 18 Aug 2023) Changed paths: M Source/JavaScriptCore/bytecode/SpeculatedType.cpp M Source/JavaScriptCore/bytecode/SpeculatedType.h M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h M Source/JavaScriptCore/dfg/DFGAbstractValue.cpp M Source/JavaScriptCore/dfg/DFGAbstractValue.h M Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp M Source/JavaScriptCore/dfg/DFGInsertionSet.cpp M Source/JavaScriptCore/dfg/DFGInsertionSet.h M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm M Source/JavaScriptCore/runtime/JSType.h Log Message: --- Cherry-pick ea191c94955d. rdar://114103295 [JSC] Make speculationFromValue cheap https://bugs.webkit.org/show_bug.cgi?id=259633 rdar://113098188 Reviewed by Mark Lam. This patch makes speculationFromValue extremely cheap by using JSType based SpeculatedType lookup. This function can be called from operationOptimize & GC End phase. And this sometimes takes very long time due to huge size of functions. Thus making this function extremely cheap is particularly important to make startup time faster. In particular, we observed massive sampling points for speculationFromValue in startup times in Speedometer2.1, Speedometer3.0, JetStream2.1, and JetStream3.0. 1. This patch removes SpecFunctionWithDefaultHasInstance and SpecFunctionWithNonDefaultHasInstance. We can just use existing Structure iteration and that can cover almost all possible cases. These type makes speculationFromValue costly for JSFunction and derived classes, so rather not so great. 2. This patch makes some functions JS_EXPORT_PRIVATE to make speculationFromValue non-JS_EXPORT_PRIVATE. So we can allow LTO / PGO to inline this if it is useful. 3. We define JSType via macro, and we list up corresponding SpeculatedType at that time. This allows us to construct a mapping between them easily, and this makes speculationFromValue just array lookup, which becomes extremely fast. * Source/JavaScriptCore/bytecode/SpeculatedType.cpp: (JSC::=): (JSC::speculationFromStructure): (JSC::speculationFromCell): * Source/JavaScriptCore/bytecode/SpeculatedType.h: * Source/JavaScriptCore/dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::validateOSREntryValue const): (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const): * Source/JavaScriptCore/dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::observeIndexingTypeTransition): (JSC::DFG::AbstractValue::validateOSREntryValue const): Deleted. (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const): Deleted. * Source/JavaScriptCore/dfg/DFGInsertionSet.cpp: (JSC::DFG::InsertionSet::insertConstant): * Source/JavaScriptCore/dfg/DFGInsertionSet.h: * Source/JavaScriptCore/llint/LowLevelInterpreter64.asm: * Source/JavaScriptCore/runtime/JSType.h: Canonical link: https://commits.webkit.org/266422@main Identifier: 265870.344@safari-7616.1.27.111-branch Commit: 9239f61644d286ec9113b9e839ec9f5ce73de721 https://github.com/WebKit/WebKit/commit/9239f61644d286ec9113b9e839ec9f5ce73de721 Author: Russell Epstein Date: 2023-09-14 (Thu, 14 Sep 2023) Changed paths: M Configurations/Version.xcconfig Log Message: --- Versioning. WebKit-7616.1.27.211.1 Canonical link: https://commits.webkit.org/265870.345@safari-7616.1.27.211-branch Commit: 0e722583a4d695c7b25f384c61fbf5b59b4c3146 https://github.com/WebKit/WebKit/commit/0e722583a4d695c7b25f384c61fbf5b59b4c3146 Author: Keith Miller Date: 2023-09-14 (Thu, 14 Sep 2023) Changed paths: A JSTests/stress/getbyoffset-cse-consistency.js A JSTests/stress/multigetbyoffset-cse-consistency.js M Source/JavaScriptCore/dfg/DFGCSEPhase.cpp M Source/JavaScriptCore/dfg/DFGClobberize.h M Source/JavaScriptCore/dfg/DFGHeapLocation.h Log Message: --- Cherry-pick 47e039ffd689. rdar://115399657 clobberize needs to be more precise with the *ByOffset nodes https://bugs.webkit.org/show_bug.cgi?id=261544 rdar://115399657 Reviewed by Yusuke Suzuki and Mark Lam. CSE phase uses clobberize to figure out if it's safe to merge two operations that def
[webkit-changes] [WebKit/WebKit] 196a65: Move IPInt slow paths to a new file
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 196a6557e7f4e12503fe4864e34c12fb06223658 https://github.com/WebKit/WebKit/commit/196a6557e7f4e12503fe4864e34c12fb06223658 Author: Keith Miller Date: 2023-09-27 (Wed, 27 Sep 2023) Changed paths: M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt A Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp A Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmSlowPaths.h Log Message: --- Move IPInt slow paths to a new file https://bugs.webkit.org/show_bug.cgi?id=261963 Reviewed by Yusuke Suzuki. This is a simple code cleanliness improvement. No code should be changed with the exception that `doWasmCallIndirect` used the wrong CALLEE macro for IPInt before. * Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj: * Source/JavaScriptCore/Sources.txt: * Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp: Added. (JSC::LLInt::shouldJIT): (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::WASM_IPINT_EXTERN_CPP_DECL): (JSC::LLInt::WASM_IPINT_EXTERN_CPP_DECL_1P): (JSC::LLInt::doWasmCall): (JSC::LLInt::doWasmCallIndirect): * Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h: Copied from Source/JavaScriptCore/wasm/WasmSlowPaths.h. * Source/JavaScriptCore/wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_SLOW_PATH_DECL): (JSC::LLInt::WASM_IPINT_EXTERN_CPP_DECL): Deleted. (JSC::LLInt::WASM_IPINT_EXTERN_CPP_DECL_1P): Deleted. * Source/JavaScriptCore/wasm/WasmSlowPaths.h: Canonical link: https://commits.webkit.org/268516@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 1b97cb: [IPInt] Add support for the exceptions proposal (e...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 1b97cb2b6e051d2f0ff0460714103eb4791a1832 https://github.com/WebKit/WebKit/commit/1b97cb2b6e051d2f0ff0460714103eb4791a1832 Author: Keith Miller Date: 2023-10-04 (Wed, 04 Oct 2023) Changed paths: M JSTests/wasm/stress/exception-simple-throw-catch.js M JSTests/wasm/stress/exception-throw-from-function-returning-tuple.js M Source/JavaScriptCore/interpreter/Interpreter.cpp M Source/JavaScriptCore/interpreter/Interpreter.h M Source/JavaScriptCore/jit/JITExceptions.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/llint/InPlaceInterpreter.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.h M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm M Source/JavaScriptCore/llint/WebAssembly.asm M Source/JavaScriptCore/offlineasm/arm64.rb M Source/JavaScriptCore/offlineasm/x86.rb M Source/JavaScriptCore/runtime/VM.h M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h M Source/JavaScriptCore/wasm/WasmFunctionParser.h M Source/JavaScriptCore/wasm/WasmHandlerInfo.cpp M Source/JavaScriptCore/wasm/WasmHandlerInfo.h M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h Log Message: --- [IPInt] Add support for the exceptions proposal (except rethrow) https://bugs.webkit.org/show_bug.cgi?id=262446 Reviewed by Justin Michaud. This patch adds support for the Wasm exceptions proposal, with the exception (pun intended) of rethrow. Rethrow is suffiecently complicated in the IPInt that it should be in its own patch. Exceptions work mostly as they do in the rest of JSC. When an exception is thrown we write the target PC and the (newly added) MC to the VM. These tell us where to go once we've reentered the IPInt. There's also two new entrypoints to the IPInt, one for regular catch blocks and one for catch_all blocks. Like the Wasm LLInt, IPInt exception handling works based on PC ranges. The current PC is (now) stored to the CallFrame's CallSiteIndex when making calls / performing operations. When an exception is thrown we check that the PC from the CallFrame is inside the range from one of the function's HandlerInfo. This patch also has a couple of other fixes/improvements: 1) offlineasm self moves should actually be elided. Previously we were checking that the two ruby objects had the same address, which didn't work. 2) Add a dump to the IPInt, which tells you what the PC and MC should be for each instruction. 3) Move the _ipint_call_impl call label below the call interpreter macros so it's clear _ipint_call_impl can fall through to .ipint_call_common. 4) Add a message to the IPInt validation so you know which opcodes are too big. 5) Rename WasmCodeBlock to UnboxedWasmCalleeStackSlot. 6) Rename LLIntReturnPC to CallSiteIndex to match CallFrame. * JSTests/wasm/stress/exception-liveness-tier-up.js: (assert.eq.): Deleted. (assert.eq): Deleted. * JSTests/wasm/stress/exception-simple-throw-catch.js: (testSimpleTryCatchValue2): (testNestedCatch): * JSTests/wasm/stress/exception-throw-from-function-returning-tuple.js: (testCatchWithExceptionThrownFromFunctionReturningTuple3): (testCatchWithExceptionThrownFromJSReturningTuple.callback): (testCatchWithExceptionThrownFromJSReturningTuple): * Source/JavaScriptCore/interpreter/Interpreter.cpp: (JSC::CatchInfo::CatchInfo): * Source/JavaScriptCore/interpreter/Interpreter.h: * Source/JavaScriptCore/jit/JITExceptions.cpp: (JSC::genericUnwind): * Source/JavaScriptCore/llint/InPlaceInterpreter.asm: * Source/JavaScriptCore/llint/InPlaceInterpreter.cpp: * Source/JavaScriptCore/llint/InPlaceInterpreter.h: * Source/JavaScriptCore/llint/WebAssembly.asm: * Source/JavaScriptCore/offlineasm/arm64.rb: * Source/JavaScriptCore/runtime/VM.h: * Source/JavaScriptCore/wasm/WasmCallee.cpp: (JSC::Wasm::IPIntCallee::IPIntCallee): * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h: * Source/JavaScriptCore/wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::getStackHeightInValues const): * Source/JavaScriptCore/wasm/WasmHandlerInfo.cpp: (JSC::Wasm::HandlerInfo::initialize): * Source/JavaScriptCore/wasm/WasmHandlerInfo.h: (JSC::Wasm::UnlinkedHandlerInfo::UnlinkedHandlerInfo): * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntGenerator::condenseControlFlowInstructions): (JSC::Wasm::IPIntGenerator::addTry): (JSC::Wasm::IPIntGenerator::convertTryToCatch): (JSC::Wasm::IPIntGenerator::addCatch): (JSC::Wasm::IPIntGenerator::addCatchToUnreachable): (JSC::Wasm::IPIntGenerator::addCatchAllToUnreachable): (JSC::Wasm::IPIntGenerator::addDelegate): (JSC::Wasm::IPIntGener
[webkit-changes] [WebKit/WebKit] 616189: [IPInt] Add rethrow
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 6161899549cff11020e444532726383465a26482 https://github.com/WebKit/WebKit/commit/6161899549cff11020e444532726383465a26482 Author: Keith Miller Date: 2023-10-06 (Fri, 06 Oct 2023) Changed paths: A JSTests/wasm/stress/try-catch-loop-osr.js M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/interpreter/Interpreter.cpp M Source/JavaScriptCore/interpreter/Interpreter.h M Source/JavaScriptCore/jit/JITExceptions.cpp M Source/JavaScriptCore/llint/InPlaceInterpreter.asm M Source/JavaScriptCore/llint/InPlaceInterpreter.h M Source/JavaScriptCore/offlineasm/arm64.rb M Source/JavaScriptCore/offlineasm/instructions.rb M Source/JavaScriptCore/runtime/VM.h M Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp M Source/JavaScriptCore/wasm/WasmBBQPlan.cpp M Source/JavaScriptCore/wasm/WasmCallee.cpp M Source/JavaScriptCore/wasm/WasmCallee.h M Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h A Source/JavaScriptCore/wasm/WasmIPIntTierUpCounter.h M Source/JavaScriptCore/wasm/WasmOMGPlan.cpp M Source/JavaScriptCore/wasm/WasmOSREntryPlan.cpp Log Message: --- [IPInt] Add rethrow https://bugs.webkit.org/show_bug.cgi?id=262704 Reviewed by Justin Michaud. This patch adds support for rethrow in the IPInt. In the other wasm tiers rethrows are saved at the top of the try/catch block's execution stack and popped when exiting the block. Since the IPInt doesn't have any metadata on End instructions (And we don't really want to add metdata there), the location of pending rethrows needs to be saved in a shadow stack. This shadow stack is located between the callframe and the locals in the IPInt frame. In order to know which shadow stack slot to store the pending exception we could save the try depth in the metadata but this would use more memory. Instead, a new field targetTryDepthForThrow has been added to VM that forwards the try depth to the catch handler from the HandlerInfo. 268872@main had a bug that it didn't restore the pointer to locals when reentering from an exception, this fixes that. We also add a new IPIntTierUpCount, which uses less memory than LLIntTierUpCount since it no longer has a mostly unused vector. Lastly, this patch adds support for load/store pair (int width) in the offlineasm. * JSTests/wasm/stress/try-catch-loop-osr.js: Added. (import.Builder.from.string_appeared_here.import.as.assert.from.string_appeared_here.loopOSRWithRethrow.callback): (import.Builder.from.string_appeared_here.import.as.assert.from.string_appeared_here.loopOSRWithRethrow): (loopOSRWithMultiRethrow1.callback): (loopOSRWithMultiRethrow1): (loopOSRWithMultiRethrow2): * Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj: * Source/JavaScriptCore/interpreter/Interpreter.cpp: (JSC::CatchInfo::CatchInfo): * Source/JavaScriptCore/interpreter/Interpreter.h: * Source/JavaScriptCore/jit/JITExceptions.cpp: (JSC::genericUnwind): * Source/JavaScriptCore/llint/InPlaceInterpreter.asm: * Source/JavaScriptCore/llint/InPlaceInterpreter.h: * Source/JavaScriptCore/offlineasm/arm64.rb: * Source/JavaScriptCore/offlineasm/instructions.rb: * Source/JavaScriptCore/runtime/VM.h: * Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck): * Source/JavaScriptCore/wasm/WasmBBQJIT.cpp: (JSC::Wasm::BBQJIT::makeStackMap): * Source/JavaScriptCore/wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): * Source/JavaScriptCore/wasm/WasmCallee.cpp: (JSC::Wasm::IPIntCallee::IPIntCallee): * Source/JavaScriptCore/wasm/WasmCallee.h: * Source/JavaScriptCore/wasm/WasmFunctionIPIntMetadataGenerator.h: (JSC::Wasm::FunctionIPIntMetadataGenerator::tierUpCounter): * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntGenerator::addLoop): (JSC::Wasm::IPIntGenerator::addTry): (JSC::Wasm::IPIntGenerator::addCatchToUnreachable): (JSC::Wasm::IPIntGenerator::addCatchAllToUnreachable): (JSC::Wasm::IPIntGenerator::addRethrow): (JSC::Wasm::IPIntGenerator::finalize): * Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::WASM_IPINT_EXTERN_CPP_DECL): * Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h: * Source/JavaScriptCore/wasm/WasmIPIntTierUpCounter.h: Added. (JSC::Wasm::IPIntTierUpCounter::IPIntTierUpCounter): (JSC::Wasm::IPIntTierUpCounter::optimizeAfterWarmUp): (JSC::Wasm::IPIntTierUpCounter::checkIfOptimizationThresholdReached): (JSC::Wasm::IPIntTierUpCounter::optimizeSoon): (JSC::Wasm::IPIntTierUpCounter::osrEntryDataForLoop const): * Source/JavaScriptCore/wasm/W
[webkit-changes] [WebKit/WebKit] 75cec0: Crash under PlatformCALayerRemote::recursiveBuildT...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 75cec00a439631f768dea754cf68c753c63ce185 https://github.com/WebKit/WebKit/commit/75cec00a439631f768dea754cf68c753c63ce185 Author: Simon Fraser Date: 2023-10-09 (Mon, 09 Oct 2023) Changed paths: A LayoutTests/compositing/reflections/video-mask-reflection-crash-expected.txt A LayoutTests/compositing/reflections/video-mask-reflection-crash.html M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp Log Message: --- Crash under PlatformCALayerRemote::recursiveBuildTransaction() https://bugs.webkit.org/show_bug.cgi?id=259607 rdar://32076163 Reviewed by Tim Horton. In some scenarios, we can end up with a PlatformCALayerRemote which remains in a sublayer list after being deleted. The testcase has a which toggles from composited to non-composited and back. This video has a mask, and a reflection. The reflection RendeLayer (the RenderReplica's layer) remains composited. When this happens, the masks layer's clone remains in the sublayer list of the "replica flattening" layer, but it's owning reference, in the LayerClones struct owned by the video layer, went away when the video stopped being composited temporarily. The real issue is that we failed to rebuild the sublayer list of the "replica flattening" layer in this case, so make sure we trigger that. * LayoutTests/compositing/reflections/video-mask-reflection-crash-expected.txt: Added. * LayoutTests/compositing/reflections/video-mask-reflection-crash.html: Added. * Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp: (WebCore::GraphicsLayerCA::setReplicatedLayer): Originally-landed-as: 265870.224@safari-7616-branch (73eb68ead0fc). rdar://116426044 Canonical link: https://commits.webkit.org/269097@main Commit: 538c84a313edd834976fd519fc3aea603aa5a167 https://github.com/WebKit/WebKit/commit/538c84a313edd834976fd519fc3aea603aa5a167 Author: Abrar Rahman Protyasha Date: 2023-10-09 (Mon, 09 Oct 2023) Changed paths: M Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp M Source/WebCore/Modules/applepay/ApplePaySetup.cpp M Source/WebCore/Modules/applepay/PaymentCoordinator.cpp M Source/WebCore/page/Page.cpp M Source/WebCore/page/Page.h Log Message: --- Ensure -[PKPaymentRequest originatingURL] is always set to the top-level document URL https://bugs.webkit.org/show_bug.cgi?id=259667 rdar://113143083 Reviewed by Andy Estes. We support Apple Pay on cross-origin iframes following 262616@main, but since we are plumbing the iframe domain rather than that of the parent document embedding said iframe, we lose some Apple Pay domain validation and abuse detection mitigations. In this patch, we preserve our existing security mitigations by passing the top-level domain to `-[PKPaymentRequest setOriginatingURL:]`. This change also aligns ourselves to the existing shipping model for payment session domain reporting in iOS 16. Note that this patch necessitates that a website provide the top level domain in its merchant session, i.e. "you can iFrame in Apple Pay, but your merchant session must use the top-level domain". This is a pre-existing invariant in PassKit, and this commit aligns WebKit in the same direction. * Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp: (WebCore::ApplePayAMSUIPaymentHandler::show): * Source/WebCore/Modules/applepay/ApplePaySetup.cpp: (WebCore::ApplePaySetup::begin): * Source/WebCore/Modules/applepay/PaymentCoordinator.cpp: (WebCore::PaymentCoordinator::beginPaymentSession): * Source/WebCore/page/Page.cpp: (WebCore::Page::startApplePayAMSUISession): * Source/WebCore/page/Page.h: Originally-landed-as: 265870.231@eng/105809792_safari-7616-branch (bb9c7e0fd205). rdar://116426149 Canonical link: https://commits.webkit.org/269098@main Commit: 08d5d17c766ffc7ca6a7c833c5720eb71b427784 https://github.com/WebKit/WebKit/commit/08d5d17c766ffc7ca6a7c833c5720eb71b427784 Author: Keith Miller Date: 2023-10-09 (Mon, 09 Oct 2023) Changed paths: A JSTests/stress/getbyoffset-cse-consistency.js A JSTests/stress/multigetbyoffset-cse-consistency.js M Source/JavaScriptCore/dfg/DFGCSEPhase.cpp M Source/JavaScriptCore/dfg/DFGClobberize.h M Source/JavaScriptCore/dfg/DFGHeapLocation.h Log Message: --- clobberize needs to be more precise with the *ByOffset nodes https://bugs.webkit.org/show_bug.cgi?id=261544 rdar://115399657 Reviewed by Yusuke Suzuki and Mark Lam. CSE phase uses clobberize to figure out if it's safe to merge two operations that def the same HeapLocation. Since HeapLocation does not currently have a way to track the offset used by the various *ByOffset nodes it can get confused and think that two ByOffset instructions produce the same value even if they don't use the same offset. This patch solves this
[webkit-changes] [WebKit/WebKit] b0bf5b: B3 should use isTuple rather than `== Tuple`
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b0bf5bc7500a53126e9c9fb1f9ee1d978db07c7c https://github.com/WebKit/WebKit/commit/b0bf5bc7500a53126e9c9fb1f9ee1d978db07c7c Author: Keith Miller Date: 2023-10-11 (Wed, 11 Oct 2023) Changed paths: A JSTests/wasm/stress/multi-tuple.js M Source/JavaScriptCore/b3/B3Type.h M Source/JavaScriptCore/b3/B3Validate.cpp M Source/JavaScriptCore/b3/air/AirCustom.cpp Log Message: --- B3 should use isTuple rather than `== Tuple` https://bugs.webkit.org/show_bug.cgi?id=261467 rdar://115283700 Reviewed by Yusuke Suzuki. Recently we switched to using the default operator== for many JSC classes (https://commits.webkit.org/267645@main). This however revealed a subtle inconsistency where we would allow Tuple TypeKinds to be compared to Types but didn't check the tuple index. Now that we use the default operator== we started checking the tuple index, which causes assertion failures in validation. To fix this validation should use `isTuple()` rather than `== Tuple`. Also, to prevent others from making the same mistake, we now `ASSERT` the implicit `Type` constructor isn't receiving a `Tuple`. * JSTests/wasm/stress/multi-tuple.js: Added. (type.1.call.1.call.0.return.export.string_appeared_here.func.2.async test): * Source/JavaScriptCore/b3/B3Type.h: (JSC::B3::Type::Type): * Source/JavaScriptCore/b3/B3Validate.cpp: * Source/JavaScriptCore/b3/air/AirCustom.cpp: (JSC::B3::Air::CCallCustom::isValidForm): Canonical link: https://commits.webkit.org/269216@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 957a22: B3::Type::tupleFromIndex should cast to Type rathe...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 957a228b92949857664d8a02f418ee2fb8484f0c https://github.com/WebKit/WebKit/commit/957a228b92949857664d8a02f418ee2fb8484f0c Author: Keith Miller Date: 2023-10-12 (Thu, 12 Oct 2023) Changed paths: M Source/JavaScriptCore/b3/B3Type.h Log Message: --- B3::Type::tupleFromIndex should cast to Type rather than call the constructor https://bugs.webkit.org/show_bug.cgi?id=263075 rdar://problem/116864571 Reviewed by Justin Michaud. Right now tupleFromIndex calls the constructor which triggers an assert. Instead we should just cast the encoded TypeKind to a Type. * Source/JavaScriptCore/b3/B3Type.h: (JSC::B3::Type::tupleFromIndex): Canonical link: https://commits.webkit.org/269253@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] eeb0d7: Speculation failure ValueProfile buckets should be...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: eeb0d7b78c6d38aec83236b93e54cb60f89fc41c https://github.com/WebKit/WebKit/commit/eeb0d7b78c6d38aec83236b93e54cb60f89fc41c Author: Keith Miller Date: 2023-10-20 (Fri, 20 Oct 2023) Changed paths: M JSTests/microbenchmarks/fold-multi-get-by-offset-to-get-by-offset.js M JSTests/stress/fold-multi-get-by-offset-to-get-by-offset-with-watchpoint.js M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/bytecode/CodeBlock.cpp M Source/JavaScriptCore/bytecode/CodeBlock.h R Source/JavaScriptCore/bytecode/LazyOperandValueProfile.cpp M Source/JavaScriptCore/bytecode/LazyOperandValueProfile.h A Source/JavaScriptCore/bytecode/LazyValueProfile.cpp A Source/JavaScriptCore/bytecode/LazyValueProfile.h M Source/JavaScriptCore/bytecode/MetadataTable.h M Source/JavaScriptCore/bytecode/MethodOfGettingAValueProfile.cpp M Source/JavaScriptCore/bytecode/ValueProfile.h M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp M Source/JavaScriptCore/dfg/DFGPredictionInjectionPhase.cpp M Source/JavaScriptCore/jit/JIT.cpp M Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/tools/HeapVerifier.cpp M Source/WTF/wtf/ConcurrentVector.h Log Message: --- Speculation failure ValueProfile buckets should be lazy https://bugs.webkit.org/show_bug.cgi?id=263335 rdar://problem/117159824 Reviewed by Yusuke Suzuki. Currently, ValueProfiles contain two JSValue buckets by default, one for LLInt/Baseline execution and one for values from speculation failures in the DFG/FTL. These are both stored inline in the ValueProfile itself. While we regularly use the regular buckets, it's somewhat rare to use the speculation failure buckets. This patch makes the speculation failure buckets lazy and part of the same data structure we use for LazyOperandValueProfiles. Not all ValueProfiles use the new lazy mechanism, arguments' ValueProfiles still have the speculation failure buckets inline and have a new type ArgumentValueProfile. This change is about a .2% improvement on our internal memory benchmarks. This change adds a new `appendConcurrently()` method to ConcurrentVector, which properly fences between the initialization of the new element and the corresponding size increment. Also, skip some tests that started failing on 32-bit. * Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj: * Source/JavaScriptCore/Sources.txt: * Source/JavaScriptCore/bytecode/CodeBlock.cpp: (JSC::CodeBlock::setNumParameters): (JSC::CodeBlock::updateAllNonLazyValueProfilePredictionsAndCountLiveness): (JSC::CodeBlock::updateAllLazyValueProfilePredictions): (JSC::CodeBlock::dumpValueProfiles): (JSC::CodeBlock::valueProfilePredictionForBytecodeIndex): * Source/JavaScriptCore/bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfileForArgument): (JSC::CodeBlock::lazyValueProfiles): (JSC::CodeBlock::lazyOperandValueProfiles): Deleted. * Source/JavaScriptCore/bytecode/LazyOperandValueProfile.cpp: Removed. * Source/JavaScriptCore/bytecode/LazyOperandValueProfile.h: (): Deleted. * Source/JavaScriptCore/bytecode/LazyValueProfile.cpp: Added. (JSC::CompressedLazyValueProfileHolder::computeUpdatedPredictions): (JSC::CompressedLazyValueProfileHolder::initializeData): (JSC::CompressedLazyValueProfileHolder::addOperandValueProfile): (JSC::CompressedLazyValueProfileHolder::addSpeculationFailureValueProfile): (JSC::LazyOperandValueProfileParser::initialize): (JSC::LazyOperandValueProfileParser::getIfPresent const): (JSC::LazyOperandValueProfileParser::prediction const): * Source/JavaScriptCore/bytecode/LazyValueProfile.h: Added. * Source/JavaScriptCore/bytecode/MetadataTable.h: (JSC::MetadataTable::valueProfileForOffset): * Source/JavaScriptCore/bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::emitReportValue const): * Source/JavaScriptCore/bytecode/ValueProfile.h: (JSC::ValueProfileBase::computeUpdatedPredictionForExtraValue): (JSC::MinimalValueProfile::MinimalValueProfile): (JSC::ValueProfile::ValueProfile): (JSC::ValueProfile::offsetOfFirstBucket): (JSC::ArgumentValueProfile::ArgumentValueProfile): (JSC::UnlinkedValueProfile::update): (JSC::ValueProfileWithLogNumberOfBuckets::ValueProfileWithLogNumberOfBuckets): Deleted. * Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * Source/JavaScriptCore/dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * Source/JavaScriptCore/jit/JIT.cpp: (JSC::JIT::compileAndLinkWithoutFinalizing): * Source/JavaScriptCore/llint/LLIntOffsetsExt
[webkit-changes] [WebKit/WebKit] c0ddab: Load compact ClassInfo from structure correctly in...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c0ddab9c4c8f0b03d9f1f471c3883b1fd95eb7a7 https://github.com/WebKit/WebKit/commit/c0ddab9c4c8f0b03d9f1f471c3883b1fd95eb7a7 Author: David Degazio Date: 2023-12-15 (Fri, 15 Dec 2023) Changed paths: A JSTests/stress/ClassInfo-across-structure-transition.js M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp Log Message: --- Load compact ClassInfo from structure correctly in FTL https://bugs.webkit.org/show_bug.cgi?id=263356 rdar://115494572 Reviewed by Mark Lam. Currently, FTL assumes loading the m_classInfo from a structure is a loadPtr on all platforms - this is not the case, since ClassInfo is represented as a 32-bit CompactPtr on platforms with 36-bit addresses. As a result, when loading the ClassInfo in some FTL nodes, it results in a junk value with the lower bits being the unshifted ClassInfo address, and the upper bits being taken erroneously from m_transitionPropertyName. This patch introduces a new loadCompactPtr() helper to FTLLowerDFGToB3 that correctly loads and shifts compact pointer fields, which in current FTL is just Structure.m_classInfo. * JSTests/stress/ClassInfo-across-structure-transition.js: Added. (calling): * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileFunctionToString): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): Originally-landed-as: 267815.353@safari-7617-branch (20234c667f25). rdar://119597685 Canonical link: https://commits.webkit.org/272160@main Commit: b600073ca93043073733879f37051cec72c99811 https://github.com/WebKit/WebKit/commit/b600073ca93043073733879f37051cec72c99811 Author: Chris Dumez Date: 2023-12-15 (Fri, 15 Dec 2023) Changed paths: A LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash-expected.txt A LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash.html M Source/WebCore/html/HTMLPlugInImageElement.cpp Log Message: --- Assertion hit under Document::dispatchPagehideEvent() https://bugs.webkit.org/show_bug.cgi?id=263204 rdar://116715579 Reviewed by Ryosuke Niwa. Delay the load if we're not allowed to run script right now. Scheduling a load will cancel / stop any pending load, which may cause events to be fired and script to run. The synchronous code path is kept when we're allowed to run script to avoid breaking tests such as: - imported/w3c/web-platform-tests/css/css-writing-modes/abs-pos-non-replaced-icb-vlr-*.xht - imported/w3c/web-platform-tests/html/semantics/embedded-content/the-iframe-element/sandbox_004.htm - imported/blink/svg/dom/viewspec-*.html - fast/css/acid2.html * LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash-expected.txt: Added. * LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash.html: Added. * Source/WebCore/html/HTMLPlugInImageElement.cpp: (WebCore::HTMLPlugInImageElement::requestObject): Originally-landed-as: 267815.354@safari-7617-branch (c34793cc5793). rdar://119597568 Canonical link: https://commits.webkit.org/272161@main Commit: 7b97f35198fd00c74cd21c039e4e56c9f5a1876f https://github.com/WebKit/WebKit/commit/7b97f35198fd00c74cd21c039e4e56c9f5a1876f Author: Dan Glastonbury Date: 2023-12-15 (Fri, 15 Dec 2023) Changed paths: M Source/ThirdParty/ANGLE/src/libANGLE/Context.cpp Log Message: --- [ANGLE] Clear pending program linking in Context::onDestroy rdar://116661298 Reviewed by Kimmo Kinnunen. When destroying Context, ANGLE resets any internal state before releasing allocated objects, such as Programs and Shaders. When destroying a program, any pending program linking is resolved via Program::resolveLink. This results in trying to access the Context state that’s just been reset, leading to a nullptr access. To work around this, we ensure there are no pending links before resetting the Context state. * Source/ThirdParty/ANGLE/src/libANGLE/Context.cpp: (gl::Context::onDestroy): * Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestGraphicsContextGLCocoa.mm: (TestWebKitAPI::TEST_F): Originally-landed-as: 267815.356@safari-7617-branch (d32cd290f021). rdar://119597554 Canonical link: https://commits.webkit.org/272162@main Commit: ecb7da686a5066eea209b6f4b2b6dcddbd0d551f https://github.com/WebKit/WebKit/commit/ecb7da686a5066eea209b6f4b2b6dcddbd0d551f Author: Keith Miller Date: 2023-12-15 (Fri, 15 Dec 2023) Changed paths: A JSTests/stress/array-iterator-to-this.js M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp M Source/JavaScriptCore/dfg/DFGClobbersExitState.cpp Log Message: --- Array iterator creation intrinsics need ToThis https://bugs.webkit.org/show_bug.cgi?id=263408 rdar://113898245 Reviewed by Yusuke Suzuki. Currently, we don't ToThis the 'this' value when we
