trimming: Support finalizers

[JeffBezanson]

This is sufficient to get finalizers working. Before merging this though I propose generalizing it by adding a new builtin calledge (or something) that we'd use like so:

function finalizer(@nospecialize(f), @nospecialize(o))
    _check_mutable(o)
    Core.finalizer(f, o)
    calledge(Tuple{typeof(f), typeof(o)})
    return o
end

function Core.Task(@nospecialize(f), reserved_stack::Int=0)
    calledge(Tuple{typeof(f)})
    Core._Task(f, reserved_stack, ThreadSynchronizer())
end

which says that if a call to finalizer is reachable, then so is f(o) etc. The implementation would be basically identical to what's here currently.

[topolarity]

adding a new builtin calledge (or something) that we'd use like so

I was thinking perhaps Core._predeclare_call(foo, a, b)

[vchuravy]

Could we instead use the existing CallInfo pieces? E.g. We already have a FinalizerInfo

julia/Compiler/src/stmtinfo.jl

Line 455 in b265dba

struct FinalizerInfo <: CallInfo

.

I am thinking something like:

indirect(::CallInfo) = false
indirect(::FinalizerInfo) = true

if indirect(callinfo)
    enqueue(workqueue, callinfo.call)
end

and then we could add TaskInfo and so forth.

One note is

julia/Compiler/src/stmtinfo.jl

Line 460 in b265dba

add_edges_impl(::Vector{Any}, ::FinalizerInfo) = nothing

Maybe we "just" need to change that to actually add the edge?

[topolarity]

IIUC the optimizer destroys the CallInfo so we unfortunately can't forward this edge from inference in the usual way

[vchuravy]

I am still not convinced of the utility of a new builtin like predeclare_call, that feels unnecessary since inference ought to have all the information already.

If we truly need it, could we merge it into precompile?

[topolarity]

I am still not convinced of the utility of a new builtin like predeclare_call, that feels unnecessary since inference ought to have all the information already.

I'm not super pleased about it either - but I also don't know of an alternative for atexit-like patterns:

const atexit_handlers = Callable[]
push!(atexit_handlers, f) # we know the identity of `f` on the `push!`

run_atexit() = for handler in atexit_handlers
    handler() # we know longer know the identity of the handlers here
end

This is pretty challenging, and also very common in practice. Even if we add this "virtual edge" to the runtime (via predeclare_call or similar), it is not tracked properly if you happen to serialize an object that needs this edge tracked

(that happens to not be the case for atexit since those are cleared, but other type-erased callbacks like LazyString could easily be carried over from pre-compilation)

If we truly need it, could we merge it into precompile?

Perhaps. That's what I called it in the first prototype, but @JeffBezanson has been keeping the entrypoint stuff separate for now, since there's little trade-off to declaring a precompile but potentially quite a lot of cost for declaring an entrypoint (or a "virtual edge") since it bloats --trim output and grows the body of static-dispatch-only code

[vchuravy]

So the problem is two-fold?

1. The expression of a virtual edge for inference sake?
2. Turning said virtual edge into an entry edge for trimming?

My expectations was that we could just turn these missing edges in inference into real edges there, e.g. teach it to look at the Task constructor and treat it as if it is a call, and that ought to add it to its real edge list? And that one could use the precompile built-in to express such a virtual edge.

For cases like atexit, the problem is more that we have two "separate" inference entries, and their is indeed no information flow possible. I agree that in that case we need to mark these functions as entrypoints, but that seems independent for me from how we handle these calls when they are visible in inference?

[vtjnash]

My expectations was that we could just turn these missing edges in inference into real edges there, e.g. teach it to look at the Task constructor and treat it as if it is a call, and that ought to add it to its real edge list? And that one could use the precompile built-in to express such a virtual edge.

We could do something more like you describe, but it seemed likely to end up being more complicated than is useful. We don't actually want to compile most "real edges" here, we only want to compile "invoke edges" which are often derived from inlined or de-virtualized copies instead. Those edges also run under a different interpreter than the parent (NativeInterp @ current-world, never the inherited one), so it is inconvenient to have to pass around multiple interpreters inside of each NativeInterp in the off-chance that someone is running a trim build and will want to recover that information later.

Since this code is trim-relevant, we already know the code to precisely compute the call signature is already required (we need to check that every dispatch is covered or is a builtin function not on the disallow-list), so checking that this is one of a set of specific functions is already visible to the code here.

The tricky case is ones like atexit, where we do not easily have the tools to correctly express that it should expect the possibility of a runtime dispatch later for the lifetime of the object it was based upon (which might have come from either compile or runtime or even earlier in the sysimg creation). Inside a single process, this would be adequately modeled already by OpaqueClosure (fixed world hidden edge) or struct CFunction (dynamic world hidden edge), but neither of those survive serialization at present.

[topolarity]

@JeffBezanson this should be ready to go from my end

I'm happy to remove the Core._predeclare_all builtin for now so that we can tackle use case that separately - I'll defer to others to make that call.

AFAIU, that's only immediately useful for Task anyway, since we have no way to use this except for call-sites that Inference cannot see.

[JeffBezanson]

This seems like an odd place to put this optimization. Is it really that helpful? If so, should it be added to fill!? Or we could add a proper zero! function.

[JeffBezanson]

Oh I see now this was for bootstrapping. Why isn't fill! available here though; isn't array.jl loaded first?

[topolarity]

The fill! implementation we need here is from multidimensional.jl since it's for a Memory:

julia> @which fill!(m, 0)
fill!(A::AbstractArray{T}, x) where T
     @ Base multidimensional.jl:1141

[JeffBezanson]

Ah. Seems to me that should be in abstractarray.jl.

[JeffBezanson]

If we're going to have predeclare_call (and I think we should) then we should use it to handle finalizer, Task, and atexit. Is there a compelling reason to make finalizers special but not other cases?

[vchuravy]

Those edges also run under a different interpreter than the parent

That's only true for fianlizer/atexit that will run with invoke latest, but not Task which inherits the world?

Since this code is trim-relevant,

The reason I am pushing back is that I don't really like "poluting" the IR for trim, especially when the information is right next to it. The only case where that isn't the case is atexit, where we need some way of registering it.

[JeffBezanson]

OK I'm kind of sympathetic to the "polluted IR" argument. Having to manually add each case to the compiler when it could just be one line of code as needed seems so unfortunate though. Are we sure there won't be more cases?

I guess with atexit the problem is the call site for the exit handlers. There we need a different feature, which I think has been referred to as "unsafe_call", AKA a "trust me bro" call site. For that it seems having something in the IR is unavoidable?

[topolarity]

I've decided to split off the Core._predeclare_call changes into a separate PR, so that we can land the finalizer support now

This should be ready to merge once CI passes.

[vtjnash]

Can you add a mention of this to NEWS (or rather, expand upon the trim entry in HISTORY) when you make the other followups also?