You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Methods like Range#include? do a Ruby super under some circumstances to delegate to a parent class. This is done from Java, which requires that calls to these methods set up a frame (indicated by frame = true in the JRubyMethod annotation).
Actual Behavior
It seems that indy call sites are not setting up frames for methods that require it. We attempt to bind directly to the Java method for native core methods, which means bypassing the logic in the DynamicMethod that would push and pop a frame. In JRuby 1.7, we would see the target needed a frame and wrap it with framing logic. In 9k, this logic seems to have been missed, probably because all our jitted Ruby methods set up their own frames now (or this would have shown up much sooner).
The benchmark provided in #3841 is enough to trigger the error. Here is is for reference. I have not come up with a smaller reproduction.
$ jruby -Xcompile.invokedynamic blah.rb
Warming up --------------------------------------
range#cover? 60.892k i/100ms
range#include?NoMethodError: super called outside of method
include? at org/jruby/RubyRange.java:630
block in blah.rb at blah.rb:10
call_times at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/benchmark-ips-2.6.1/lib/benchmark/ips/job/entry.rb:53
block in run_warmup at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/benchmark-ips-2.6.1/lib/benchmark/ips/job.rb:205
each at org/jruby/RubyArray.java:1593
run_warmup at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/benchmark-ips-2.6.1/lib/benchmark/ips/job.rb:191
block in run at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/benchmark-ips-2.6.1/lib/benchmark/ips/job.rb:172
times at org/jruby/RubyFixnum.java:291
run at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/benchmark-ips-2.6.1/lib/benchmark/ips/job.rb:171
ips at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/benchmark-ips-2.6.1/lib/benchmark/ips.rb:57
<top> at blah.rb:8
The text was updated successfully, but these errors were encountered:
Ok, looks like in 838c8d7 I removed support for CallConfiguration, which was our only way to know if core methods need a frame. So we have two options:
Continue removing support for frame = true in core method binding. We'd need to make sure those methods can properly super, which might be difficult if we don't know where in the heirarchy they are supering from.
Restore a "needs frame" bit on DynamicMethod to indicate if a frame is needed. Indy binding logic can then appropriately set up and tear down a frame.
The short-term fix will be to avoid indy binding on a framed core method, but I'll still need a way to tell that a frame is required.
Allow frame = true but rewrite the generated code (at compile time) to insert pre/post framing logic. Still would need access to the appropriate "frame klass" to know where to super from.
Environment
JRuby 9k, all versions up through 9.1.
Expected Behavior
Methods like
Range#include?
do a Ruby super under some circumstances to delegate to a parent class. This is done from Java, which requires that calls to these methods set up a frame (indicated byframe = true
in theJRubyMethod
annotation).Actual Behavior
It seems that indy call sites are not setting up frames for methods that require it. We attempt to bind directly to the Java method for native core methods, which means bypassing the logic in the DynamicMethod that would push and pop a frame. In JRuby 1.7, we would see the target needed a frame and wrap it with framing logic. In 9k, this logic seems to have been missed, probably because all our jitted Ruby methods set up their own frames now (or this would have shown up much sooner).
The benchmark provided in #3841 is enough to trigger the error. Here is is for reference. I have not come up with a smaller reproduction.
The text was updated successfully, but these errors were encountered: