-
Notifications
You must be signed in to change notification settings - Fork 52
New invalidations #418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New invalidations #418
Conversation
|
CC @vtjnash |
|
With JuliaLang/julia#57999, this is getting there. Here's what the pattern of invalidations looks like, at a high level, for method insertion invalidations: and here is the same thing for the corresponding edge invalidations: They are very similar, for example julia> SnoopCompile.AbstractTrees.print_tree(etrees[2].backedges[end]) # etrees is the list of trees from edge invalidations
MethodInstance for InvalidA.f(::Int64) at depth 1 with 3 children
├─ MethodInstance for InvalidA.alsocallsf(::Int64) at depth 2 with 0 children
└─ MethodInstance for InvalidA.callsf(::Int64) at depth 2 with 1 children
└─ MethodInstance for InvalidA.callscallsf(::Int64) at depth 3 with 0 children
julia> SnoopCompile.AbstractTrees.print_tree(mtrees[3].backedges[end]) # mtrees is the list of trees from method-insertion invalidations
MethodInstance for Main.MethodLogs.f(::Int64) at depth 0 with 3 children
├─ MethodInstance for Main.MethodLogs.alsocallsf(::Int64) at depth 1 with 0 children
└─ MethodInstance for Main.MethodLogs.callsf(::Int64) at depth 1 with 1 children
└─ MethodInstance for Main.MethodLogs.callscallsf(::Int64) at depth 2 with 0 childrenbut julia> SnoopCompile.AbstractTrees.print_tree(etrees[2].backedges[end-1])
MethodInstance for InvalidA.f(::Integer) at depth 1 with 3 children
├─ MethodInstance for InvalidA.callsfrtr(::Int64) at depth 2 with 0 children
└─ MethodInstance for InvalidA.callsfrta(::Int64) at depth 2 with 1 children
└─ MethodInstance for InvalidA.callscallsfrta(::Int64) at depth 3 with 0 children
julia> SnoopCompile.AbstractTrees.print_tree(mtrees[3].backedges[end-1])
MethodInstance for Main.MethodLogs.f(::Integer) at depth 0 with 2 children
├─ MethodInstance for Main.MethodLogs.callsfrta(::Int64) at depth 1 with 0 children
└─ MethodInstance for Main.MethodLogs.callsfrtr(::Int64) at depth 1 with 0 childrenSome of the differences make sense: for example, for method insertion, the first-to-be-inserted method triggers the invalidation, whereas for edge invalidations we attribute the invalidation to a list of matches. This is why for the edge invalidation, the trees for I'm wondering if some of the other differences, like signatures in |
These will be a separate PR
a33fb9f to
469db0f
Compare
Enable this after 1.12 is out
This is a rewrite of the invalidations infrastructure based on Julia 1.12+. Julia 1.12 separates the data into two logging streams, one for immediate method insertion/deletion and the other for edge-validation during package loading. This allows a cleaner implementation of the parsing. I've also invested in a more extensive and systematic test suite, attempting to cover all code paths, and added tests for binding invalidation. Finally, this expands the documentation on developer topics.
This is a rewrite of the invalidations infrastructure based on Julia 1.12+. Julia 1.12 separates the data into two logging streams, one for immediate method insertion/deletion and the other for edge-validation during package loading. This allows a cleaner implementation of the parsing. I've also invested in a more extensive and systematic test suite, attempting to cover all code paths. There are still some missing cases though, so far notably the binding invalidations and
"method_globalref"invalidations (which I've not yet succeeded in generating).A key feature of the new test architecture is that it's designed to try to check that you can get the same invalidation trees in either immediate or edge-validation mode. Currently, though, the edge-validation is failing due to a failure to cache all the required compilation in the InvalidB test module.
There are also a couple of changes directed at
@snoop_inference, but once I discovered that the invalidations needed updating too, I decided to start there. I'll probably strip those out before merging, and submit those changes in a separate PR.