Use cases for typed function references without GC about function-references

[RossTate]

*ping after two weeks* So, are there use cases?

[tlively]

We (WebAssembly tools team at Google) have idly discussed partitioning LLVM function pointers by type and storing them in tables of typed function references. This would save a type check on each call to a function pointer and unlock follow-on optimizations by reducing the number of functions each indirect call could potentially reach. We have no concrete plans and have not done an in-depth investigation of this idea, though.

[rossberg]

Any module interface that needs to provide functions taking callbacks, for example. Some WASI modules would be use cases.

I'm not sure why you think this might be specific to GC?

[RossTate]

Thanks, @tlively, for the info! It sounds like you're using type information to deduce aliasing information. I also have a few places where aliasing information would be useful. Maybe it'd be worthwhile to brainstorm thoughts at some point?

I'm not sure why you think this might be specific to GC?

Thanks for the good question, @rossberg. So the applications I can think of all generally associate something with the function reference. In the easiest cases, that something is just memory, e.g. an object or a closure environment. But you need at least GC to clean up that something implicitly. In the more difficult cases, like cross-module callbacks for systems like WASI, that something is a resource. Plus WASI presumably wants to work well with C/C++ wasm modules that can't rely on GC to clean up memory for them. So either way, I would expect either the module providing the callback needs some way to invalidate the callback when it has expired or the module receiving the callback needs some way to release the callback when it's no longer useful. This proposal does not seem to provide that infrastructure for function references.

So I'm looking for some concrete use cases for typed function references without GC, ones that have been fleshed out enough to encounter potentially relevant issues like the above and worked them through.

[rossberg]

I don't follow. How is that related to typing? You have the same questions with plain funcref already.

Without GC you obviously need some form of reference counting for references. And with GC, too, wrt to outside references. That's no different for functions than it is for externrefs. And it is no different from functions acquired at type funcref, or typed functions acquired via a module export for that matter. Whether typed or not, an embedder implementing host modules natively naturally will have to go through one of the respective engine's API (or a generic abstraction like the C API) to handle such Wasm refs, and these APIs all provide the relevant functionality to acquire and drop such references. Nothing is new here.

[RossTate]

As I said, memory management is only part of the problem with cross-module callbacks. But regardless, you brought up another point:

How is that related to typing? You have the same questions with plain funcref already.

Very true. But funcref was already effectively first class in the initial release, and unlike typed function references it doesn't introduce a bunch of typing complexity. So given that we have funcref, I'm also wondering if there's enough value in adding typed function references to be worth the complexity they introduce. They are barely faster (one less push, pop, and trapping equality check, and even that is optimizable across repeated calls), and so far there haven't been any use cases raised where the slight potential difference in performance would be meaningful.

[rossberg]

There has been informal agreement on the CG to land function references and GC together, so closing this.