obviously (even with the proposed change) still won't work for send-ing throught an *args method ...
... __send__ should really do a switch for its args[] version to always route same count to same place?
currently most over-loaded native methods handle the fallback but its an added complication for ext writers if they need to special account for :send every time they do an overload e.g. (arg1) + (args[])

@kares I believe anno binding will work with block and non-block signatures. I might be missing something but if we can do that I would prefer it over an if in all block accepting signatures (I guess we also need callsites to properly call those versions too -- is that the issue?). I would like to ultimately have n call paths with little to no actual extra logic to keep methods smaller/simpler for inlining potential.

@enebo ok - makes sense, callsites are fine and dispatch is all good for the normal method call.
only about that send case - which I will try to expand the overloads to non-block versions as well.
... and see whether anno binder binds them and thus can get rid of the extra logic presented here.

9K does no longer route the (arg1, arg2, arg3) case as before

Are you saying that 3-argument calls aren't going to 3-argument overrides now?

case addressed here is that Date.send(:civil) will not take the same path as Date.civil

Yes, I agree this should be addressed. I'll have a look at the patch.

Ok thoughts.

• I don't believe InvocationMethodFactory can generate stubs for methods that define both block and blockless forms. The main limitation is that there's forms of all JavaMethodXXXX with Block or without Block, but none that handles both.
• I think we need a fix inside JavaMethod to avoid boxing in cases where the provided block is not given. The block versions would do the check you have here (small added overhead to all block calls to non-block methods, not common), and then dispatch to the non-block version or the args-boxing block version. The default non-block versions would just dispatch to the args-boxing version.

I realize as I type this that this introduces a new problem: calling a method with no block that is set up to receive a block will start routing through args boxing. The problem just gets moved to the other side.

Now...I have generally tried to make sure all my args[] methods do check arity; they can be called from Java, after all, and there's no guarantee on the size of the incoming array. So with that in mind I'm wondering if we really should fix this. If we always route 0-3 args to appropriate overloads, and stop checking the args array length, we're going to have a lot of methods that are poisonous to call from Java without the right size array.

But maybe we can compromise...should we bite the bullet and try to expand the number of arities we can directly pass?

@kares I believe anno binding will work with block and non-block signatures.

confirmed (as @headius) noted we can not have block and block-less form at the same time for binder e.g.

    @JRubyMethod(name = "send", omit = true)
    public static IRubyObject send(ThreadContext context, IRubyObject self, IRubyObject arg0) {
        ...
    }
    @JRubyMethod(name = "send", omit = true)
    public static IRubyObject send(ThreadContext context, IRubyObject self, IRubyObject arg0, Block block) {
        ...
    }

thus exactly :

I don't believe InvocationMethodFactory can generate stubs for methods that define both block and blockless forms. The main limitation is that there's forms of all JavaMethodXXXX with Block or without Block, but none that handles both.

I realize as I type this that this introduces a new problem: calling a method with no block that is set up to receive a block will start routing through args boxing. The problem just gets moved to the other side.

yeah - I looked at JavaMethod first but quickly realized that it already routes non-block to block (if it exists). so while I can easily fix my problem by always having block forms I'd still like to not be run down later again.

If we always route 0-3 args to appropriate overloads, and stop checking the args array length, we're going to have a lot of methods that are poisonous to call from Java without the right size array.

point taken (although polished for core still easy to get 'ugly' bugs in user-exts - send mis-behaving).
the other approach would be to extend invoker generation to route block forms simply ignoring the blocks.
that would match up how methods implemented in Ruby work, and solve it all, maybe?

9K does no longer route the (arg1, arg2, arg3) case as before

Are you saying that 3-argument calls aren't going to 3-argument overrides now?

yep that's the case at least in interpreter as there's only OneOperandArgNoBlockCallInstr and TwoOperandArgNoBlockCallInstr

So we could fix this but we would need to redo all those types in order to handle both. My question is which is a better long-term outcome? Maybe we do not need to address all issues today but it might be a time to redo those types (or deprecate and make a new hierarchy) if it would be nicer to just have all paths in a single hierarchy. I am just asking the question though :)