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

Methods that appear to be Fixnum operators optimize poorly (in indy) when they are not #803

Closed
headius opened this issue Jun 14, 2013 · 1 comment

Comments

@headius
Copy link
Member

headius commented Jun 14, 2013

In the current indy logic for binding calls that appear to be operations against a fixnum, we only have a fast, inlinable path for the success case. If it turns out the operation is not performed against a fixnum, we follow a slower, non-inlinable path.

Calls that appear to be fixnum operators are of the form , as in the following examples:

a = b + 1
a = b * 1
a = b << 8

In cases like these, we will optimize the call to go straight into the versions of these methods on RubyFixnum that receive long rather than IRubyObject for the second operand. The guard is a simple "instanceof RubyFixnum" check.

If the guard fails, we permanently fall back to a version that mimics the old CachingCallSite, actively checking the cache entry for validity each time. This logic is much slower than standard indy dispatch and does not allow the target method to inline.

This comes into play in the Benchmarks Game "pidigits" code, since fixnums eventually roll over into bignums and the operators start failing. There are likely many other cases out there where a literal fixnum is added, subtracted, etc with a float, rational, bignum, or other value, or appended into an array.

@enebo enebo modified the milestone: JRuby 9.0.0.0 Jul 14, 2015
@enebo enebo added this to the Invalid or Duplicate milestone Feb 17, 2017
@enebo
Copy link
Member

enebo commented Feb 17, 2017

This is a valid issue but between Graal and IR work this is not really specifically an indy issue. Or at least it overlaps with other avenues of optimization now.

@enebo enebo closed this as completed Feb 17, 2017
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

2 participants