Add Libdl.LazyLibrary

[staticfloat]

This provides an in-base mechanism to handle chained library dependencies. In essence, the LazyLibrary object can be used anywhere a pointer to a library can be used (dlopen, dlsym, ccall, etc...) but it delays loading the library (and its recursive dependencies) until it is actually needed.

This is the foundational piece needed to upgrade JLLs to lazily-load their libraries. In this new scheme, JLLs would generally lose all executable code and consist of nothing more than LazyLibrary definitions.

[staticfloat]

Honestly, I'm not 100% certain I even want dlclose() defined. I don't like the refcount, I don't like that dlopen(ll) opens multiple libraries and dlclose(ll) only closes one, etc...

I think if you want to close the libraries, you just need to be responsible for closing them yourself.

[staticfloat]

Ugh, running into that windows problem where I can't rm() a .DLL I've opened.

[vchuravy]

x-ref: libuv/libuv#3839

[staticfloat]

I'm dodging the issue now by not re-using libccalltest but instead creating new (extremely small) libraries for a simple lazy dependency test.

[staticfloat]

Converting to draft while I figure out how to make the names lazier, so that we can use these with artifact"" without needing an __init__() method. Current idea; embed calls to artifact"" inside of LazyString objects.

[staticfloat]

I worked this over with Valentin today, and we arrived to the current, rather overly-clever solution. It features a few very useful implementation details:

1. It stores its name as an AbstractString, and introduces LazyStringFunc which allows users (such as JLLs) to store a callback that gets evaluated during dlopen() time. This allows us to store library paths such as artifact"foo/lib/libfoo.so", which will lower down into a runtime Artifact lookup.

2. In order to provide the ccall() magic at all stages, we need to fill out the jl_lazy_library_type and jl_libdl_dlopen_func fields. We do this in C when restoring an image, but when bootstrapping we needed a way to feed these values in just after they've been defined. We opted to Base.unsafe_store!(cglobal(:jl_lazy_library_type, Any), LazyLibrary) at the toplevel, which is either genius or madness, I'm unsure which.

Things I'm still a little unhappy about:

1. The on_load_callback invocations happen before we've updated ll.handle, which means that if you try to ccall((:foo, libfoo), ...) from within your callback, you end up in an infinite loop in dlopen() (you are supposed to use the raw handle that is passed into the callback). This is obviously nonideal as it's the most natural way of writing those callbacks (and allows re-use of existing functions); I'm thinking we should update ll.handle first, but have some other way of knowing that we have not yet finished initialization; perhaps with an atomic bool? I'm open to suggestions here.

I have a second branch that builds on top of this to make many stdlibs lazy, most importantly OpenBLAS_jll, and while it's a bigger change, it manages to get startup time down from 122ms -> 95ms on my macbook pro, and time to first matmul stays steady at 123ms.

[staticfloat]

Suggested change

	struct _LazyStringFunc <: AbstractString
	struct _LazyStringFunc

[staticfloat]

I've finished the Jameson refactor, and rebased my stdlib working branch on top of it, verifying it still works. We should be good to go here, as long as this goes green.

[staticfloat]

@vtjnash So our change to no longer only call dlopen() when the type is a LazyLibrary now causes some of the ccall tests to fail, as they now throw a MethodError instead of a TypeError. Do we want this? It's a little inconsistent with e.g. cglobal().

[vtjnash]

We should define that method and have it call a TypeError

[staticfloat]

We should define that method and have it call a TypeError

So you mean something like dlopen(::Any) = throw(TypeError(...))?

[vtjnash]

yes, like that