[loading]: Rework preferences loading

[staticfloat]

Implements the Preferences loading framework as outlined in 0. The
most drastic change is that the list of compile-time preferences is no
longer sequestered within its own dictionary, but is instead
autodetected at compile-time and communicated back to the compiler.
This list of compile-time preferences is now embedded as an array of
strings that the loader must load, then index into the preferences
dictionary with that list to check the preferences hash.

In a somewhat bizarre turn of events, because we want the .ji filename
to incorporate the preferences hash, and because we can't know how to
generate the hash until after we've precompiled, I had to move the .ji
filename generation step to after we precompile the .ji file.

[staticfloat]

@Keno analyzegc is angry at me, I believe because prefs_list could be GC'ed:

https://github.com/JuliaLang/julia/pull/38044/files#diff-f9e2818fcf6de95dcaa432fde9cea4e28109ddef7bc2fbc11849f4d6565b68d8R1143

I don't think I can use JL_GC_PUSH*() here because of the usage of prefs_list in two different scopes, unless perhaps I can JL_GC_PUSH() while prefs_list is still NULL. Is that the case?

[Keno]

Yes, the GC push is for a stack location, not a value, so you can initialize the location to null and then push it. The error is correct. You need to root that value

[staticfloat]

@vtjnash you are probably interested in this from the perspective of communication happening between the code being compiled and the compiler.

In short; when we call @load_preference("backend") in the code being compiled, Preferences calls jl_generating_output(), notes that "backend" was requested during compilation, and pushes that name onto Base. COMPILETIME_PREFERENCES[uuid]. At the end of compilation, as part of the header of the .ji file, the list of accessed top-level preferences gets serialized along with the hash of all preferences listed. This allows loading to attend only to the preferences that are included in that header list, allowing us to store compile-time preferences and non-compile-time preferences in the same dict, and not requiring the user to specifically denote which are or are not compile-time preferences. In effect, the preferences are known as compile-time purely by the virtue of them being accessed at compile-time.

This should not make it any harder or easier to disallow parsing of TOML files off of the disk at compile time. Most likely what we'd do for that is change Base.get_preferences() to look up in a global Dict whether we already have a mapping for that UUID, and if so, use it instead of trying to hit the disk. Then, if we're launching a remote compile job, we are responsible for loading preferences for all UUIDs being compiled beforehand and transmitting that to the remote compile job, such that it can pre-fill the global Dict.

[vtjnash]

Yep, I was somewhat following along and that sounded like what I expected

[staticfloat]

Great, I will merge this when green then.

[vtjnash]

Ah, wait, I don’t understand how you can look up something correctly by content hash with this scheme

[staticfloat]

Ah, wait, I don’t understand how you can look up something correctly by content hash with this scheme

I'm not sure what you mean; what is content-hashed?

[staticfloat]

@vtjnash Was your comment related to this: #38105

[vtjnash]

Yeah, that's where I noticed that lookup won't work anymore. That function maybe should be replaced with randstring for clarity?

[staticfloat]

Which function should be randstring? In general we want deterministic results so that we don't have to recompile a .ji file after flip-flopping preferences.

[staticfloat]

Spoke with Jameson, he's okay with this overall, so I'm going to merge.