Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indy call sites are not setting up frame for core methods #3842

Closed
headius opened this issue May 3, 2016 · 2 comments
Closed

Indy call sites are not setting up frame for core methods #3842

headius opened this issue May 3, 2016 · 2 comments

Comments

@headius
Copy link
Member

headius commented May 3, 2016

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 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
@headius
Copy link
Member Author

headius commented May 9, 2016

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.

@headius
Copy link
Member Author

headius commented May 9, 2016

There's a third option:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant