So, the basic premise here is that the only source of use of some of the frame fields comes from the ruby stdlib, and for the JRuby impls in Java, those can be annotated, and optimized around.

Looks like this PR is asserting that this claim is true for the backref field.

Are there any frame fields where that premise doesn't hold?

i.e. can non-stdlib ruby methods directly (vs indirectly via use of stdlib methods) affect use of any of these frame fields?

@subbuss Non-stdlib methods could only affect this if they were also defined in Java and annotated to access these fields.

We do update the list of methods that might need frame fields as they are defined, so if a third-party lib has a JRuby extension and some methods that need frame, the list of "might need a frame" method names will get updated. However this is obviously timing-sensitive.

I chatted with @enebo about ways to mitigate this risk.

The main potential problem with this PR is the following scenario:

• A method contains calls that are known to need backref.
• The method also contains calls that need other frame fields, but for whatever reason we can't see that (aliasing, for example).
• Now we will only set up space for backref.
• Additional frame use will not be initialized or cleared properly.

This requires a lot of things to align. The most likely way to have a method call that needs framing but doesn't get it is to alias one of the core methods. This is done rarely, since aliasing is usually used to wrap a method, and you can't wrap methods that access the caller's frame. The other way to trigger this problem is as you mentioned, a third-party library that is using our annotations.

@subbuss Non-stdlib methods could only affect this if they were also defined in Java and annotated to access these fields.

I see, so default in the absence of annotations is requiring the full frame?

That default question comes from: can a pure ruby method have code that can affect use of any frame field? I suppose that only applies to the backref field since that is the only one you opt right now.

@subbuss It is not possible for pure Ruby code to access the caller's frame unless it is passed a binding or closure (which can be turned into a binding).

To clarify...a method can certainly have its own calls to [] or binding or whatever, but that's different than needing access to the caller's frame, like several core methods do. It's not possible to access the caller's frame from Ruby unless it was handed to you.

Ah, right. I forgot that detail .. been a while. :) Didn't look at the code closely, but the idea lgtm.