Suggestion: Use different precompilation cache path for different system image

[tkf]

With PackageCompiler.jl, it is easy to create custom system images. I think it would be useful if you can create a custom image for some Julia projects you use repeatedly. However, it is hard to use different system images since all the precompilation cache files are stale after switching the system image. This patch makes it possible to use dedicated set of cache files for each system image. Each system image is identified by its path so that precompilation cache files used for Julia master are updated in-place after you pulled and build Julia (as oppose to increase disk usage for each pull).

(As a side-effect, this patch can be used as a workaround of #27418.)

[StefanKarpinski]

@vtjnash, @KristofferC: I'm not sure this is the way we want to do this, but since no one's come up with anything better yet, this issue is still a big annoyance.

[tkf]

@StefanKarpinski By "a big annoyance", do you mean #27418? It was not my intention to present this PR as the solution for #27418 (because it's not). The purpose for this PR is supporting multiple system images, not multiple projects. I think the issue with multiple projects has to be solved separately.

[StefanKarpinski]

"Big annoyance" = that precompile files from different package environments (including Julia version) end up clobbering each other, which means that if you switch environments you get lots of recompilation. So this is part of the problem but far from the whole thing.

[tkf]

no one's come up with anything better yet

I suggested one idea a while ago. I also just posted a quick implementation for #27418 in: #27418 (comment) I hope it re-starts the discussion.

[KristofferC]

It seems this will leave a lot of old precompilation files around after messing around with binary paths etc.

Perhaps this can just be incorporated into the method used for the project cache (which is capped at 10) by adding something to:

julia/base/loading.jl

Lines 1194 to 1195 in 88c34fc

	project_precompile_slug = slug(_crc32c(something(Base.active_project(), "")), 5)
	abspath(cachepath, string(entryfile, "_", project_precompile_slug, ".ji"))

[tkf]

Thanks for the feedback. That is a good idea. I updated the patch.

[KristofferC]

@tkf, thinking back to this couldn't we just have a random suffix after the _ when we create a new precompile file. What's the advantage of mixing in the julia binary and sysimage etc.

[tkf]

That's because I wrote this before your #32651 and didn't realize that the random suffix could do the trick.

So, IIUC your point, a random suffix approach would work because stale_cachefile would reject the cache file compiled with a different system image?

[KristofferC]

Oh, if you did it before that, I understand.

And yes, exactly that. For example, @staticfloat is putting some extra stuff in that can invalidate the cache with the Preferences package so right now the order that invalidates the cache had to be mixed in there as well. But we already have a function to check if the cache is stale so might as well just use that.

[tkf]

Well, I honestly don't know if I could come up with the trick :) It's very clever! And yeah, I can see that we can use this to support compile-time preferences.

[staticfloat]

I guess the difference in behavior is that if you change versions in your project right now, it will not change the suffix, so it will overwrite, whereas if it's just random, you will generate a new one, and eventually the LRU cache of precompiles will start eliminating other, potentially useful .ji files. So you could fill up your LRU cache of 10 precompiles quickly with a single project, causing unnecessary cache thrashing, whereas right now it will overwrite its own slot much more often.