Partition runtime-function caching away from the precompilation boundary

[gbaraldi]

Fixes the miscompilation reported in JuliaGPU/AcceleratedKernels.jl#123 (and the class behind it): on Julia 1.13, every bounds-checked kernel fails with InvalidIRError: unsupported dynamic function invocation (call to kernel_state()) — but only for users whose GPU matches the target that the back-end's precompile workload compiled (for AMDGPU.jl 2.8.0: gfx1030 + wavefront 32, i.e. every real RDNA2 user; other targets, and hence CI, are unaffected, which is what made this hard to see).

Root cause. During a back-end package's own precompilation, its workload compiles a kernel; that builds the GPU runtime library, and the resulting owner-tagged CodeInstances are serialized into the package image. Those CodeInstances carry inferred code where calls that inference normally resolves remain dynamic (getproperty of kernel_state()::Any — decompressed from AMDGPU's image, the stored source for signal_exception has Base.getproperty as a plain :call). On Julia 1.13, supports_relocatable_ir() is unconditionally true, so both the CodeInstances and the per-function runtime bitcode built from them persist across the boundary. At runtime, a job whose cache-owner token is egal to the workload's revives them: the linked runtime library contains ijl_apply_generic / jl_f_throw_methoderror, and IR validation rejects the kernel. Fresh sessions without a matching image entry compile the identical code cleanly — inference is fine; only artifacts revived across the precompilation boundary are not.

Fix.

• runtime_config now derives a dedicated cache owner, RuntimeCacheToken(parent, generating), which additionally records whether output was being generated. Runtime-function CodeInstances therefore never cross the precompilation boundary in either direction. Only the handful of runtime methods are affected — they re-infer once per session in microseconds — while kernel-level CodeInstance reuse (the TTFK win from package images) is untouched.
• emit_function! validates runtime modules for dynamic-dispatch fallbacks (ijl_apply_generic, jl_invoke, jl_f_*): poisoned cached bitcode is discarded and recompiled instead of linked, and poisoned fresh emissions are never cached. This also heals existing poisoned images without waiting for them to be rebuilt.

Verification. Backported onto v2.6.0 and tested against registry AMDGPU.jl 2.8.0 on Julia 1.13.0: the previously deterministic gfx1030 failure compiles cleanly, gfx942 stays green, and the built runtime library contains zero dynamic calls. Native test suite passes with the new tests (runtime owner partition + fallback detection).

Root cause found (JuliaGPU/AMDGPU.jl#1075): generators run in their defining world, and AMDGPU's @generated kernel_state() references AMDGPU.KernelState, defined after the device include. During AMDGPU's own precompilation the intra-package world ordering is live, the generator throws UndefVarError: KernelState not defined in AMDGPU, and Compiler.get_staged silently swallows it ("user code might throw errors – ignore them") — inference then types the call Any and the poisoned CodeInstance is cached. After image serialization the method and binding worlds collapse to the image-load world, which is why every other context expands the generator fine and the poison is only ever created at that one site.

AMDGPU.jl#1075 fixes the ordering and adds a workload assertion; this PR remains the structural protection — any backend can hit the same silent get_staged failure (an upstream Julia issue worth filing: real generator errors deserve a debug-visible path), and runtime-function CodeInstances should not cross the precompilation boundary regardless.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FJL9JQhcpXUVWkhuuiA7ad

[vchuravy]

That seems wrong? If the Runtime can be dynamic, why couldn't it be at normal runtime? This seems like the classic order constraint on generated functions?

[maleadt]

This is a Julia "property", where generators run in their definition world, so AMDGPU.jl needs to define kernel_state after the KernelState struct is defined just like other back-ends do.

[codecov]

Codecov Report

❌ Patch coverage is 88.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.44%. Comparing base (cf51f4f) to head (2692659).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/rtlib.jl	86.95%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #933      +/-   ##
==========================================
- Coverage   85.78%   85.44%   -0.35%     
==========================================
  Files          29       29              
  Lines        5613     5633      +20     
==========================================
- Hits         4815     4813       -2     
- Misses        798      820      +22     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.