Add "localized world age" fast-path to staticdata.jl

[topolarity]

This PR introduces the notion of "localized world age" (see the added devdocs) and adds a fast path to staticdata.jl

On my machine, this saves us ~420k of the ~720k method look-ups that we perform (~58%) for loading "using CairoMakie".

The load-time improvements are more modest (about ~1-1.5 seconds) since these were already very fast (~3 μs on average) and we still spend a lot of time walking to these edges that we don't need to verify.

I suspect there are more gains to be had here. The fast-path is moderately warm, but most of the non-fast-pathed calls are targeting "dense" MethodTables, like (::Type)(...) or highly ad-hoc-polymorphic tables like haskey(...) which will be implemented over many user types.

It should be possible to generalize this to have sub-MethodTable granularity like this (numbers made up):

world (age: 12342)
├─ haskey (age: 484)
│    ├─ haskey(::T, ...) where moduleroot(parentmodule(typename(T))) === Base (age: 201)
│    ├─ haskey(::T, ...) where moduleroot(parentmodule(typename(T))) === PkgFoo (age: 12)
│    └─ haskey(::T, ...) where moduleroot(parentmodule(typename(T))) === PkgBar (age: 34)
├─ read (age: 200)
...

which would make many of those eligible for the fast path at the cost of an extra lookup or two.

Nonetheless, I wanted to open this first to get input (esp. @vtjnash's and @timholy's) and see if this approach is sound (and to work out how to best do the edge encoding etc. - it's not very efficient right now)

[Keno]

Copilot suggests the following change:

diff --git a/test/core.jl b/test/core.jl
index 4f27c4896d..4bb7f8fe32 100644
--- a/test/core.jl
+++ b/test/core.jl
@@ -36,7 +36,7 @@ for (T, c) in (
         (Core.CodeInstance, [:next, :min_world, :max_world, :inferred, :edges, :debuginfo, :ipo_purity_bits, :invoke, :specptr, :specsigflags, :precompile, :time_compile]),
         (Core.Method, [:primary_world, :deleted_world]),
         (Core.MethodInstance, [:cache, :flags]),
-        (Core.MethodTable, [:defs, :leafcache, :cache, :max_args]),
+        (Core.MethodTable, [:defs, :leafcache, :cache, :max_args, :last_update_world, :local_age]),
         (Core.TypeMapEntry, [:next, :min_world, :max_world]),
         (Core.TypeMapLevel, [:arg1, :targ, :name1, :tname, :list, :any]),
         (Core.TypeName, [:cache, :linearcache]),

[timholy]

This is a really interesting idea. I've been trying to figure out a way that I can confuse the local_age by using sneaky tricks of loading packages in different orders, but so far I think you're OK: the combination of the fact that age always increases, that precompilation always occurs in a minimal world, and the fact that you don't actually need a specific local age for each method seems (as far as I can tell) to make this safe.

Divorcing local_age from the session's world age will also make this more broadly applicable. So this seems sound to me. Really nice contribution!

[timholy]

Any reason not to hoist this typeassert out of the loop?

[topolarity]

It's not a necessary type-assert, but it's to make it explicit that we're testing both the type and the value of the entry in the edge list (a UInt is a local age, but an Int is the number of MethodInstances in an edge bundle)

This version is probably clearer:

Suggested change

	if edges[i] === (nmatches::Int) && edges[i+2] == info.atype
	if edges[i] isa Int && edges[i] == nmatches && edges[i+2] == info.atype

[timholy]

I don't know this code well, but I'm confused about why the condition doesn't cause edges to go out of register.

[topolarity]

What do you mean by out of register?

[timholy]

nvm, I misread. I thought it was always skip-3, but it's not.

[timholy]

I think of "the method table" as meaning the table for a specific function, and thus I initially interpreted this as something specific to a subset of the signatures in a given MethodTable. Maybe you mean "specific portions of the global method cache"?

[topolarity]

Good point.

"cache" is not quite what I mean either, since we are not allowed to drop these entries, but I think "portions of the global dispatch table" is probably closer to what I mean

[vchuravy]

Nice! A while back Jameson and I were bouncing an idea back and forth of "opaque" world ages and defining them in terms of "union of visible things", we struggled with how to write efficient queries, but IIUC "local world age" is a step in this direction. Essentially, a world-age is a (still linearized) union of all "local world" ages.