use a fixed world for code loading

[KristofferC]

Code loading Base.require is one function that keeps getting run over and over as packages gets loaded. It is therefore important that this function does not get invalidated because having to recompile it causes significant latency. A lot of work has been done trying to shield it from invalidations but it seems to be a never ending battle. During the loading of OmniPackage.jl for examples, I have seen code loading gotten recompiled 4 times during the loading of that package.

A possible solution is to run the code loading code in a fixed world age thereby making it immune to invalidations (since it keeps running the old code). This also means that the code cannot be straight forwardly Revised, but maybe that is a price worth paying.

cc @c42f, @timholy, @JeffBezanson, @vtjnash

[c42f]

This seems like a good tradeoff to me.

If people want to circumvent this when they're developing the loading code, can't they just do

Base._require_world_age[] = typemax(UInt)

?

[oscardssmith]

can this also be done for repl tab completions?

[c42f]

This can and probably should be done for any Julia "session infrastructure" or compiler-related stuff which is

• Implemented on the Julia side
• Does not need to be extended by users
• Suffers from invalidations due to package loading

REPL keybindings are an interesting case - we can't choose a fixed world for all key bindings because packages add to the keybinding mappings. Rather, packages which extend the keybindings need to choose an appropriate world age when the keybinding is installed. For example I did this for OhMyREPL in KristofferC/OhMyREPL.jl#321

If the REPL had an API for adding keybindings, it would make sense to capture the world age when the keybinding was added and to replace the current use of invokelateset() within the REPL with invoke_in_world.

However that's a separate PR.

[KristofferC]

After #49604, I am not sure I have a concrete case in the wild where this is needed.

[c42f]

I still think it's a good idea to shield this (and other) parts of the Julia core implementation from user invalidations. (With an opt-out for Base developers, which we do have here.)

We already have this for Core.Compiler, and basically have had for a long time before invoke_in_world existed (implemented at the C level). Why not also have it for other critical parts of the runtime?

[KristofferC]

Okay, I am seeing require getting invalidated again now so now I want to do this again hah.

[c42f]

I found a neat way to express the fixed world age in

JuliaLang/JuliaSyntax.jl#290

So an option would be to steal the fix_world_age function from there, if it helps:

https://github.com/JuliaLang/JuliaSyntax.jl/blob/68d3fbd300fd3d03e69bfc1e99bb7eb7dcd47030/src/hooks.jl#L107

[KristofferC]

Hm, for this specific case, I don't think it brings much clarity over just doing it manually.

[KristofferC]

@nanosoldier runtests(vs = ":master")

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected.
A full report can be found here.

[KristofferC]

Let's try this then.