Repository navigation
ci: bump actions/github-script from 6 to 9 - #1
Open
dependabot[bot] wants to merge 1 commit into
Open
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [actions/github-script](https://github.com/actions/github-script) from 6 to 9. - [Release notes](https://github.com/actions/github-script/releases) - [Commits](actions/github-script@v6...v9) --- updated-dependencies: - dependency-name: actions/github-script dependency-version: '9' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Zerotwo63
referenced
this pull request
in Zerotwo63/melonx-performance
Oct 6, 2026
…tics sheet The previous "Copy JIT Diagnostics" button, attached to a SwiftUI .alert, looked like it did nothing: an alert dismisses the instant any button is tapped, with nowhere to confirm the copy worked or read the result. Real on-device test confirmed the clipboard ended up empty. Replaced with "View JIT Diagnostics", which presents a real sheet (JITDiagnosticsView, new) showing the full report as selectable text - independent of the clipboard. Copy/Share/Close are real buttons; Copy shows "Copied" inline without closing the sheet; the report is also written to Documents/jit-diagnostics.txt so the data survives even if the clipboard path fails for any reason. Per-method tracking is now much richer (JITMethodAttempt: detected, enabled, attempted, startTime, endTime, result, error, underlyingError, errno, timeout, pairingStatus, connectionStatus) via a new updateAttempt() mutator, instead of one fixed finishAttempt(result:, error:) call. JITDiagnostics.probeExecutableMemory() does a real mmap+mprotect with errno captured, called after every method that claims to have acquired JIT - never trusting a method's own boolean. JITCoordinator.beginRetry() adds a "===== JIT RETRY #N =====" marker to the log without clearing it, so retry AzureDominus#2 can be compared against #1 in one continuous transcript. Code investigation (done before changing behavior, per instruction): confirmed 4 real JIT methods exist (JITStreamerEB internal, TrollStore, StikDebug/StikJIT external via detectStikTool()/canOpenURL - not the old private SpringBoardServices API, Built-in StikJIT via the embedded helper extension + pairing file) and their fixed if/else-if execution order in LaunchGameHandler.enableJIT(). Confirmed NativeSettingsManager's builtInStikJIT/stikJIT accessed as a property (.value) in one file and as a function (builtInStikJIT(false)) in another are the same underlying Setting<Bool> (@dynamicMemberLookup currying), not a discrepancy. Keys/firmware/setup untouched, per explicit instruction - that flow is confirmed working on the user's real device. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0154M6e32Hb3UdRAetwiQ7Lz
Zerotwo63
referenced
this pull request
in Zerotwo63/melonx-performance
Oct 7, 2026
…i-state, CS_DEBUGGED gate, diagnóstico por región Causa raíz encontrada (no solo diagnóstico): ProcessInfo.hasTXM (archivo TrustedExecutionMonitor.img4) es un heurístico de archivo que puede no encontrar el firmware en este iOS 26/27 + A19 Pro, devolviendo "ausente" sin poder probarlo. Como DualMappedJitAllocator.hasTXM leía directamente ese resultado binario, tomaba la rama de mmap/mprotect plano en vez de BreakGetJITMapping (BreakpointJIT.framework, que YA implementa exactamente el protocolo JIT26PrepareRegion/JIT26Detach documentado por StikJIT: mov x16,#1/brk #0xf00d/ret y mov x16,#0/brk #0xf00d/ret, con x0=address/x1=length) - produciendo memoria que mprotect(PROT_READ|PROT_EXEC) reporta como éxito pero que mach_vm_region confirma como NON_EXECUTABLE_MAPPING. El mismo hasTXM==false también hace que StikEnableJIT.swift omita el script al lanzar StikDebug, dejando un adjunto de depurador plano sin el bucle que atiende los breakpoints. FIX #1 (TXM tri-state, requisito 5): ProcessInfo.txmStatus ahora devuelve Present/NotPresent/Unknown explícitamente - Unknown solo colapsa a notPresent en iOS <26 (donde TXM no existe por definición); en iOS 26+, un archivo no encontrado es Unknown, nunca NotPresent. hasTXM (Bool) se mantiene como shim de compatibilidad = txmStatus != .notPresent, así que BreakGetJITMapping/StikEnableJIT's script attachment/LiveContainer check heredan el camino seguro sin tocar sus call sites. DualMappedJitAllocator.TxmStatus hace el mismo parseo en C# del valor de 3 estados que HAS_TXM ahora transporta ("1"/"0"/ "unknown", nunca binario). FIX AzureDominus#2 (CS_DEBUGGED gate, requisitos 2/3B): DualMappedJitAllocator ahora comprueba csops(getpid(), CS_OPS_STATUS, ...) & CS_DEBUGGED ANTES de ejecutar el brk - si el protocolo es requerido pero no hay debugger/script conectado todavía, lanza Jit26NotReadyException en vez de ejecutar el breakpoint a ciegas (que de todas formas ya habría sido neutralizado sin daño por JIT26BreakpointHandler, el manejador SIGTRAP existente que avanza PC+4 y limpia x0 - pero ahora el motivo de fallo es explícito y distinguible). JITCoordinator ya reintenta initialize_dualmapped() en cada poll (~0.5s) vía isJITEnabled(), así que el siguiente intento tras adjuntar el debugger reintenta automáticamente sin cambios adicionales. Localización de TODAS las regiones RX de LightningJit (requisito 1): DualMappedNoWxCache's _sharedCache + _localCache (construidas en DualMappedTranslator.InitializeDualMapped(), arranque de la app) y NativeSignalHandler's _codeBlock (su propio trampolín, con MemoryBlock.Detach() ya existente llamado justo después) - las tres pasan por DualMappedJitAllocator.AllocateDualMapping(), que es donde se instrumentó todo. Secuencia real confirmada: las tres regiones se preparan ANTES de que el único Detach() se dispare (requisito 4 ya satisfecho estructuralmente, no requirió cambios). Diagnóstico nuevo (requisito 6): jit26ProtocolRequired, csDebugged, jit26ScriptConnected, jit26PrepareCalls/Successes, jit26RegionIndex/ OriginalAddress/Length/PreparedAddress/PrepareReturned, jit26DetachAttempted/Returned, jitReadyBeforeRegionPreparation (logueado en LaunchGameHandler justo antes de que arranque cualquier intento de JIT esta sesión). Post-JIT26 validation (requisitos 7/8): postJit26PlainProbeReturned/ Value y postJit26BtiProbeReturned/Value - companions de dispatchProbeReturned/Value, usando el MISMO allocator real (_dualMappedCache/_noWxCache vía RunSameMapProbe), nunca el canal diagnóstico de single-map de la ronda anterior. classifyWatchdogFailure() distingue ahora "JIT26 protocol required but not attached" de un timeout genérico cuando jit26ProtocolRequired=true y csDebugged=false. LiveContainer (requisito 9): sin cambios de comportamiento - StikEnableJIT.swift/LaunchGameHandler's LiveContainer branch ya leían ProcessInfo.hasTXM, que ahora es más fiable automáticamente. Piezas que NO pertenecen a MeloNX/Ryujinx (requisito 10, explícito): el script debugger-side (universal.js-equivalente, ya en MeloNXJITHelper/MeloNXBreakpointScript.swift y StikEnableJIT.swift) depende de que StikDebug/StikJIT esté realmente instalado y atendiendo PID - eso no es código de este repo, solo se puede verificar en dispositivo real adjuntando StikDebug. No se tocó Vulkan/MoltenVK/swapchain/RenderLoop/GPU FIFO/firmware-keys, ni DispatchLoop, ni Translator.GetOrTranslate, por instrucción explícita de esta ronda. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0154M6e32Hb3UdRAetwiQ7Lz
Zerotwo63
referenced
this pull request
in Zerotwo63/melonx-performance
Oct 7, 2026
…tor.Clear() dejaba el allocator compartido sin bloques libres
CAUSA RAÍZ CONFIRMADA (leyendo el código real, no adivinada):
Translator.Dispose() (ejecutado al cerrar un juego, vía
LightningJitCpuContext.Dispose()) llamaba _dualMappedCache.Dispose()
sobre originalDualMappedCache - el singleton PROCESS-WIDE que
DualMappedNoWxCache reutiliza entre sesiones de juego en iOS. Eso
cascadea a MemoryCache.Dispose() -> CacheMemoryAllocator.Clear(), que
tenía un bug real: dejaba _blocks completamente VACÍO en vez de
reponer un único bloque libre con la capacidad completa (la misma
garantía que el constructor establece). Toda llamada posterior a
Allocate() recorre una lista vacía y devuelve -1 inmediatamente,
interpretado por MemoryCache.Allocate() como
OutOfMemoryException("JIT Cache exhausted") - exactamente lo que el
segundo juego golpea en su primera asignación real, dentro de
TranslatorStubs.Map (prueba exacta de "Map begin" sin "Map end": la
excepción se lanza DENTRO de ese método, antes de llegar al log de
"Map end").
Esto es además arquitectónicamente incorrecto independientemente del
bug de Clear(): el mapping RW/RX JIT26-preparado de ese cache es
estado de PROCESO (una vez preparado vía el protocolo de StikDebug/
BreakGetJITMapping, no se puede re-preparar tras el detach), no estado
de SESIÓN DE JUEGO - disponerlo al cerrar un solo juego está mal
incluso si Clear() funcionara perfecto.
FIX #1 (bug real, independiente): CacheMemoryAllocator.Clear() ahora
repone un bloque libre cubriendo toda la capacidad, igual que el
constructor.
FIX AzureDominus#2 (diseño de lifetime correcto, PROCESS JIT STATE vs GAME SESSION
JIT STATE): nuevo DualMappedNoWxCache.EndGameSession() - limpia
_functionMetadata/_pendingMap (vía el nuevo PageAlignedRangeList.Clear())
y resetea los CacheMemoryAllocator de _sharedCache/_localCache a
completamente libres, SIN tocar el allocator/mapping subyacente.
Translator.Dispose() ahora llama EndGameSession() en vez de Dispose()
cuando _dualMappedCache ES el singleton compartido
(ReferenceEquals(_dualMappedCache, originalDualMappedCache)); el caso
genuinamente per-sesión (ruta no-TXM, not-yet-firstSet) sigue usando
Dispose() real, sin cambios. Functions (caché estático de funciones
traducidas por dirección guest) se resetea incondicionalmente en cada
Dispose() - direcciones guest de juegos distintos SÍ colisionan, una
entrada stale ejecutaría código del juego anterior bajo la dirección
del nuevo.
Instrumentación añadida (sessionId incremental, nunca se resetea):
"GAME SESSION N start/shutdown begin/threads stopped/JIT dispose/
mappings released/translator disposed/shutdown complete",
jitRegionCountBeforeShutdown/AfterShutdown, jitMappingsReleased,
jitDisposeAttempted, jitStateReset, threadLocalCachesReset (mapeado al
reset real de Functions, documentado así explícitamente - no hay
counter público de hilos guest sin tocar Ryujinx.HLE, fuera de
alcance), dispatchStubReset, translatorDisposed. "threads stopped" es
un marcador de ORDEN (Translator.Dispose solo se alcanza tras que el
teardown de HOS/Horizon ya paró los hilos guest de este título), no
una medición independiente - documentado así, no fabricado.
Program.cs: stop_emulation entered/returned, ExecutionEntrypoint
emulationContext dispose begin/end.
Tests: CacheMemoryAllocatorTests/PageAlignedRangeListTests (NUnit,
Ryujinx.Tests) - prueban exactamente el bug confirmado (Allocate tras
Clear() debe funcionar), sin dependencia de DualMappedJitAllocator
(ese sí requiere mmap/vm_remap reales de Darwin, no testeable en CI
multiplataforma). Requirió agregar
[assembly: InternalsVisibleTo("Ryujinx.Tests")] a Ryujinx.Cpu
(src/Ryujinx.Cpu/AssemblyInfo.cs, nuevo) para poder probar estos tipos
internal sin ampliar su superficie pública. Como con todo test de
C# en este fork, build.yml/checks.yml solo ejecutan `dotnet test` en
pull_request, no en push directo a perf/jit-integration - verificado
por lectura/lógica y por el build real de CI, no por ejecución.
Objetivo 2C: Info.plist gana GitCommitSHA/GitBranch (vacíos en el
repo), poblados por un nuevo paso de CI
("Record build identifiers") vía plutil + git rev-parse HEAD /
GITHUB_REF_NAME antes de xcodebuild. SettingsView.swift los muestra
bajo "Version X.Y" en el header de Settings ("Build
<branch>@<sha10>"), con fallback honesto a "unknown" si el Info.plist
nunca pasó por ese paso de CI (build local/manual).
No se tocó Vulkan/MoltenVK/swapchain/GPU FIFO/firmware-keys, ni
DispatchLoop, ni el trabajo JIT26 de la ronda anterior (BreakGetJITMapping/
BreakJITDetach/CS_DEBUGGED siguen intactos - este fix opera en la capa
de arriba, el ciclo de vida del Translator/cache, no en el protocolo
de preparación de regiones en sí).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0154M6e32Hb3UdRAetwiQ7Lz
Zerotwo63
referenced
this pull request
in Zerotwo63/melonx-performance
Oct 8, 2026
…5-P99 a Swift AUDITORÍA REALIZADA (Fase 1-4 del pedido, alcance acotado dado el tamaño): investigación directa del código real (no teórica) en Ryujinx.HLE.PerformanceStatistics, Ryujinx.Graphics.Vulkan.PipelineBase, Ryujinx.Graphics.Gpu.Shader.ShaderCache, y los managers Performance/* ya mergeados en rondas anteriores (BenchmarkManager/FramePacingMonitor/ AutoPerformanceManager/MemoryGuard/ThermalGovernor/ShaderCacheInspector) - confirmados REALES y conectados (no stubs), no solo por existir la clase sino verificando el recorrido completo hasta su fuente de datos real (RyujinxBridge.currentFPS -> Device.Statistics.GetGameFrameRate(), CADisplayLink, ProcessInfo.thermalState). HALLAZGO #1 (confirmado, implementado): Device.Statistics.GetFifoPercent() (% de tiempo que el procesador de comandos GPU estuvo realmente activo, ventana de ~750ms) y GetGameFrameTime() ya existían en el core, pero SOLO se usaban en el título de ventana de las UIs de escritorio (Ryujinx/AppHost.cs, Ryujinx.Gtk3, Ryujinx.Headless.SDL2/WindowBase.cs) - nunca expuestos a iOS/Swift. FIFO% es una métrica genuinamente independiente (no derivable de FPS) que distingue frames limitados por GPU de frames limitados por CPU/JIT - exactamente lo que el pedido de auditoría necesita. Expuesto vía nuevo export nativo get_gpu_fifo_percent -> RyujinxBridge.gpuFifoPercent -> BenchmarkManager.Result.gpuFifoPercent -> PerformanceOverlay. GetGameFrameTime() deliberadamente NO se expuso - es una derivación pura de la misma FPS ya reportada (1000/frameRate), y BenchmarkManager.swift ya documentaba esta razón exacta de una ronda anterior. En su lugar, se calculan P95/P99 reales de frametime a partir de frameIntervals (deltas reales de CADisplayLink.targetTimestamp que BenchmarkManager YA recolectaba para worstFrameJitter, nunca antes usados para percentiles) - una medición genuinamente independiente de la distribución real de tiempos de frame, no otra forma de expresar el promedio de FPS. HALLAZGO AzureDominus#2 (confirmado, implementado, mayor impacto esperado): PipelineBase.cs creaba su VkPipelineCache SIEMPRE vacío (PipelineCacheCreateInfo sin InitialData) y lo destruía en Dispose() sin guardar su contenido - confirmado por lectura directa del constructor y Dispose(bool). A diferencia de la caché de SHADERS (Ryujinx.Graphics.Gpu.Shader.ShaderCache + DiskCacheHostStorage, que SÍ persiste a disco por título y SÍ se reutiliza entre lanzamientos - confirmado, no asumido), la caché de OBJETOS PIPELINE (que se construyen sobre shaders ya compilados) se reconstruía íntegra en CADA lanzamiento del mismo juego, y cualquier combinación de estado nunca vista antes durante el juego seguía costando el mismo stutter en cada sesión en vez de solo la primera vez en la vida del juego. Corregido: se guarda/carga un blob único (no por título - un VkPipelineCache es válido entre títulos distintos que comparten estado, a diferencia de los shaders; el propio driver verifica pipelineCacheUUID/versión en el header y descarta un blob incompatible sin error, por especificación de Vulkan) en AppDataManager.BaseDirPath/cache/vulkan_pipeline_cache.bin, vía vkGetPipelineCacheData (dos llamadas: tamaño, luego datos) justo antes de vkDestroyPipelineCache, y como InitialData al crear la caché la próxima vez. Aditivo y seguro por diseño: un blob corrupto/incompatible simplemente se ignora (el mismo comportamiento que ya tenía antes, caché vacía), nunca un error nuevo. RIESGO conocido y explícito: GetPipelineCacheData no se pudo verificar contra el paquete NuGet real de Silk.NET.Vulkan en este entorno (no restaurado localmente) - la firma usada (ref nuint dataSize, byte* dataPtr) sigue exactamente el patrón de dos llamadas del propio vkGetPipelineCacheData y el estilo 1:1 ya usado en este mismo archivo para CreatePipelineCache/DestroyPipelineCache, pero el único mecanismo real de verificación disponible aquí es el build real de CI. MetalFX Spatial (pedido explícito del usuario): auditado, NO implementado esta ronda - MetalFXCapabilityInspector.swift (ronda anterior) ya había confirmado que el punto de intercepción necesario vive enteramente en el código nativo C#/.NET del swapchain Vulkan/ MoltenVK (MeloMTKView/MetalViewContainer no tocan el frame en absoluto). Verificado esta ronda: ningún mecanismo de interop VkImage<->MTLTexture (vkGetMTLTextureMVK o equivalente) se usa en todo el repo, y no hay headers de MoltenVK vendoreados para confirmar que la build de MoltenVK empaquetada aquí expone esa función - implementar a ciegas, sin Xcode/dispositivo para verificar, en la ruta de presentación ACTIVA y funcional, es exactamente el riesgo que esta ronda pide evitar explícitamente. No se añadió "MetalFX Spatial" como opción en Settings (seguiría la regla explícita de "no controles falsos sin conexión real al backend"). No se tocó JIT/LightningJit, DualMappedJIT, adquisición de JIT, firmware/keys, ni el flujo de sesiones (MoltenVKWindow.cs's DisposeGpu() fix de rondas anteriores permanece intacto) - confirmado por git status antes de este commit. Tests: ninguno nuevo esta ronda (el cálculo de percentiles es lógica pura extraíble pero no se extrajo a una unidad testeable por separado dado el alcance ya cubierto; GetPipelineCacheData no es testeable sin un contexto Vulkan/MoltenVK real). Verificado por lectura de código y por el build real de CI únicamente. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0154M6e32Hb3UdRAetwiQ7Lz
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps actions/github-script from 6 to 9.
Release notes
Sourced from actions/github-script's releases.
... (truncated)
Commits
3a2844bMerge pull request #700 from actions/salmanmkc/expose-getoctokit + prepare re...ca10bbdfix: use@octokit/core/types import for v7 compatibility86e48e2merge: incorporate main branch changesc108472chore: rebuild dist for v9 upgrade and getOctokit factoryafff112Merge pull request #712 from actions/salmanmkc/deployment-false + fix user-ag...ff8117eci: fix user-agent test to handle orchestration ID81c6b78ci: use deployment: false to suppress deployment noise from integration tests3953cafdocs: update README examples from@v8to@v9, add getOctokit docs and v9 brea...c17d55bci: add getOctokit integration test joba047196test: add getOctokit integration tests via callAsyncFunctionDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)