I suspect this is due to a numeric optimization that bypasses the known Ruby core method and goes straight to other logic. We would just want to register those other method names so that they are transformed into a core method backtrace line.

If you specify -Xbacktrace.style=full, you'll see all the intermediate and Ruby lines together in a single trace.

This may originally have been because we had some special-case methods for faster math operations. Now the root cause is that all these methods are defined on RubyInteger, which is how they're entered into the backtrace scrubber. But when dispatched against RubyFixnum or RubyBignum, they don't ever pass through RubyInteger, so that trace line is lost.

Brainstorming a fix...

We could make the Ruby-bound methods redispatch to a different name, so they would not be overridable (and could be marked as final to ensure they don't get overridden. However all dispatches from within RubyInteger would be bimorphic against RubyFixnum and RubyBignum, rather than the original call site seeing only one or the other.

We could modify the JRubyMethod annotation, or the processing of it, to list or find subclass overrides, and also add those classes to the mapping table for method names. If this were done manually, it would be error-prone, and done automatically would require digging up all child classes during populator generation. It's doable though.

We could introduce another annotation used to generate a populator for the name mapping, It would be another build step and another generated piece of code to run on boot, but it could accurately reflect all class/method combinations we want to map to a different Ruby name, including specialized locations such as our "helpers" classes or utility methods in the interpreter. This seems like the best idea, but has the most work involved.

@enebo Gimme your $0.02!

There's a bit more complication here with the Integer integration.

Our backtraces are based on matching an exact class plus method name in the Java trace, which works fine for classes that implement their own Ruby-facing methods. RubyInteger, however, has mostly abstract implementations of these methods, implemented in the two subclasses RubyBignum and RubyFixnum. That prevents the stack trace from reflecting the RubyInteger class and as a result none of these methods will show up in a Ruby trace.

This is a specific example of the general problem that methods not directly bound via @JRubyMethod will not show up in Ruby traces.

I have pushed a PR that should fix this, at least for Integer, Method/UnboundMethod, and the specialized Array subtypes for one and two-element lists. We will land that for 9.3.