Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Split frame fields to reduce pre/post logic #4905
One of the primary perf hits in JRuby comes from methods that need a method frame to store data for downstream calls. An example: because there's one
Unfortunately, there's problems with how we manage this now:
This PR starts the process of splitting frame push/pop logic to be more fine-grained, allowing for initializing only the parts of the frame we need.
At the moment, this PR does the following:
In experiments, for a method that contains a call to
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?
@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:
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.
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.
To clarify...a method can certainly have its own calls to