Add binding invalidations to log

[timholy]

Currently we log the invalidated backedges of a binding invalidation, but the actual trigger of the invalidation is not logged. This is needed to allow SnoopCompile to attribute a cause to those invalidations.

[Copilot]

Pull Request Overview

This PR adds logging for binding invalidations to help SnoopCompile attribute a cause to these events.

• Introduces the jl_maybe_log_binding_invalidation function in src/gf.c.
• Augments the debug logging mechanism by appending both the triggering value (if non-null) and a location tag.

Files not reviewed (3)

• base/invalidation.jl: Language not supported
• test/precompile.jl: Language not supported
• test/worlds.jl: Language not supported

Comments suppressed due to low confidence (1)

src/gf.c:1842

• [nitpick] Consider adding tests for jl_maybe_log_binding_invalidation to ensure it logs correctly in both cases when 'replaced' is non-null and when it is null.

JL_DLLEXPORT void jl_maybe_log_binding_invalidation(jl_value_t *replaced)

[Keno]

This seems potentially problematic, because the invalidated code instances will get interleaved with nested invalidations from other bindings. Can SnoopCompile disambiguate this?

[Keno]

Also should probably check if anything was actually invalidated by adding appropriate boolean returns.

[timholy]

Thanks, that's exactly the answer I was fishing for.

[timholy]

WRT interleaving, here's what the log looks like now:

12-element Vector{Any}:
  MethodInstance for Main.Test98Main_worlds.makelbi(::Int64)
 1
  MethodInstance for Main.Test98Main_worlds.makelbi(::Int64)
  "jl_maybe_log_binding_invalidation"
  BindingPartition 39141:39152 - constant binding to @world(Main.Test98Main_worlds.LogBindingInvalidation, 39141:39152)
  "jl_maybe_log_binding_invalidation"
  MethodInstance for getproperty(::Module, ::Symbol)
 1
  MethodInstance for Main.Test98Main_worlds.flbi()
 2
  BindingPartition 39146:39155 - constant binding to @world(Main.Test98Main_worlds.LogBindingInvalidation, 39141:39152)(1)
  "jl_maybe_log_binding_invalidation"

Is your concern that if other types depend on LogBindingInvalidation, the sequencing in the log may become confusing to parse?

With this implementation from the second commit, I had to define makelbi to trigger logging for the type invalidation. (The global const glbi invalidation happens regardless.) Not sure exactly which behavior we prefer.

[Keno]

The interleaving concern is that if there is a backedge between bindings, it is ambiguous, whether a particular CodeInstance was invalidated by the outer binding or by an inner recursion to invalidate_code_for_globalref!

[timholy]

Good point. I think this fixes it.

It's worth noting that, unless I'm not looking in the right places, there's little to no direct testing of bindings with backedges. rebinding.jl is what I was missing!