Reduce overhead of binding Java classes and methods#5832
Merged
headius merged 12 commits intojruby:masterfrom Sep 16, 2019
Merged
Reduce overhead of binding Java classes and methods#5832headius merged 12 commits intojruby:masterfrom
headius merged 12 commits intojruby:masterfrom
Conversation
This reduces the amount of method scanning needed to boot up a given class. The filtered ClassValues filter out methods that will not be accessible, and then goes on to separate out the static methods.
31ece51 to
6b45d64
Compare
For classes which have no static methods to bind, this was creating a map unnecessarily. There will never be classes that have no instance methods (since they all eventually descend from object) but the consistency seems better here.
For Map iteration, this avoids creating intermediate Set and Iterator objects, plus all the transient Map.Entry objects. For List iteration, this eliminates the Iterator. Both cases may require allocating the lambda object and introduce boot-time overhead to instantiate the lambda class, but overall this patch should reduce allocation along these paths.
This may not improve load times since we only do this once for each bound class, rather than doing it for classes in that bound class's hierarchy.
Note it's not really lazy yet because RubyToJavaInvoker calls initialize immediately and most upstream logic eagerly prepares the payload. This commit also removes the intermedate installer for constructors.
* Avoid repeated security exceptions by caching empty method lists * Localize more method-gathering state and logic into MethodGatherer class * Clean up some visibility and organization.
headius
added a commit
to headius/jruby
that referenced
this pull request
Nov 26, 2019
* Private classes were considered for method binding even though we no longer set them accessible on Java 9+ when they have not already been opened. This resulted in Java 9+ environments producing method errors when they attempted to dispatch to those methods on private classes. * In order to fix the above for private classes with public interfaces, this patch also fixes how we traverse a class's implemented interfaces. Possibly from changes in jruby#5832, we were not walking an interface's superinterfaces, causing us to only walk one level in such cases.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a work-in-progress to reduce the overhead of our initial setup and binding of Ruby proxy classes for Java classes.
There's a number of places in this binding logic where we re-scan or re-partition methods, as well as creating a large number of transient data objects that are thrown away once the class is bound. I will be trying to find a way to pipeline more of this process to avoid the intermediate state objects.