Support passing objects as function/method arguments

[rfk]

It is not currently possible to pass objects as arguments to functions or methods, apart from the special-case handling of the implicit first argument in a method call.

In theory this should be easy right? You accept the u64 handle as an argument, look up the object in the appropriate handle-map, and you're off to the races!

There are significant complexities in practice. I don't think we need this functionality with any urgency but I wanted to put a bug on file for why this is harder than it might seem. Some thoughts below, please comment with others if you have them.

If the object argument needs to be mutable, then we can't just grab the object out of the handle-map, we have to use a closure that manages locking for exclusive access. If we have several object arguments, we would need to codegen a series of nested closures, which could get messy fast.

Mutable object arguments are also a deadlock hazard. Imagine a function call that takes two object arguments, like modify(obj1, obj2), and a concurrent call to modify(obj2, obj1). If we naively try to access each object argument in turn inside the generated FFI function, then the first call will lock obj1, and second call will lock obj2, and then they'll both deadlock waiting for the lock on their second argument. We might be able to mitigate that by locking object arguments in a consistent order, such as always trying to lock arguments with lower numeric handles first. But that'll make the codegen even messier.

┆Issue is synchronized with this Jira Task

[rfk]

Ref #366 (comment) for a concrete use-case for this.

Also of note: the proposal for reducing locking in #368 might also help us with the deadlock hazard described above, or at the very least would help make the deadlock hazard visible in the code instead of being hidden away in the generated bindings.

[rfk]

This is now possible as of v0.12.0