jruby -X-C -S rails new blankapp works in f1eca7a but fails in 5f717bd ... those are somewhat arbitrary commits in the end-August to late-October timeframe.

Maybe worth bisecting if simple to do. Otherwise, will take a look over the weekend.

Started bisecting ... good in c7a3739 .. bad in 23a3d2f.

Finished and it fingered 0630462 .. but turning off the pass in master doesn't fix it. Will investigate tomorrow. It will also help find a regression spec.

Looked into this a little bit. If I disable frame-removal optimization in AddCallProtocolInstructions.java (replace "return requiresFrame" with "return true" .. line 150 of that file), this works again.

The reason I came to this is by finding that the 'self' used to verify access protection is not the same as the receiver passed into the call. This is because invoke methods in RubyClass.java use "IRubyObject caller = context.getFrameSelf();" to test access protections. So, if a frame has been eliminated for these scopes, it uses the wrong object to test access protection!

Pinging @headius and @enebo to see what the right fix is for this. But, I am also curious why RubyClass.java:invoke is using frame-self rather than the 'self' that has been passed in. If there is a reason for doing that, 'doesItRequireFrame' method requires an update to not eliminate frames that have these 'invoke' calls.

We also need a regression spec for this.

Ah never mind .. I get it .. access protection has to use the self of the caller's frame. So, there is an information gap here in the doesItRequireFrame method.

Looking around, looks like attr-assign instructions are the only users of Helpers.invoke(..) .. so, the easy fix was to add a computeScopeFlags() to that and fix it. However, a better fix would be to explicitly pass in the caller-self into Helpers.invoke(..) since that is available rather than try to get it off the frame stack.

Longer term, we should be able to make access-protection checks, method lookups, etc. as separate instructions which could then be optimized away in certain scenarios.

While the regression spec is passing via jruby -S rspec, in actuality, default jruby run fails the test. But, jruby -X-C passes it. See below. So, the attr_reader access check is not working in JIT mode?

[subbu@earth lib] jruby /tmp/boo.rb
[nil, 10]
[subbu@earth lib] jruby -X-C /tmp/boo.rb
["NoMethodError", 10]
[subbu@earth lib] cat /tmp/boo.rb
class C
def update(v); self.v = v; end

protected
attr_accessor :v
end

a = []
begin
a << C.new.v
rescue => e
a << e.class.name
end

begin
a << C.new.update(10)
rescue => e
a << e.class.name
end

p a

Opening a new issue for this.