James Wrigley (Oct 10 2025 at 20:07): James Wrigley (Oct 10 2025 at 20:07):Does anyone know what could be done about these invalidations from defining a Base.lock method for a new IO type? https://github.com/JuliaLang/IJulia.jl/issues/1192#issuecomment-3390755056
I have a very vague understanding of invalidations but the code in IJulia/the MWE looks ok to me so I don't fully grok why it causes so many of them.
Jakob Nybo Nissen (Oct 11 2025 at 10:11):It's hard to tell precisely without digging into it, but it looks very much like an ordinary invalidation due to world splitting.
There is nothing you can do about it. It's an explicit tradeoff in the Julia compiler. The compiler does a bunch of speculative compilation, that just sometimes gets invalidation without anyone having done anything wrong.
The upside is that a lot of poorly inferred code runs fast due to this speculative compilation.
You can try to lobby the core devs to make the compiler stop doing this kind of speculative compilation, but that's kind of it.
James Wrigley (Oct 11 2025 at 11:49):Alas :tear: Thanks for the help.
Neven Sajko (Oct 11 2025 at 14:16):This should be easy to fix by setting max_methods to one for Base.lock. However that needs to be done in Base. I have some relevant PRs I want to get back to some time. This one, specifically:
Neven Sajko (Oct 11 2025 at 14:18):The other, more laborious, approach is to fix the code that is actually vulnerable to invalidation (because of type instability).
Jakob Nybo Nissen (Oct 11 2025 at 14:28):IO code in particular is often intentionally despecialized - e.g. with types having a field marked ::IO, so I doubt it can be fixed
Neven Sajko (Oct 11 2025 at 14:55):As I said, it's just a matter of disabling world-splitting for lock.
Neven Sajko (Oct 11 2025 at 14:57):However I feel like this should be done more comprehensively, instead of on a function-by-function basis, thus the linked PR. The PR does not currently include any changes for lock, though.
Last updated: Oct 18 2025 at 04:39 UTC