Details
-
Type:
Improvement
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: JRuby 1.5
-
Fix Version/s: None
-
Component/s: Java Integration
-
Labels:None
-
Number of attachments :
Description
For JRUBY-4734, we discovered that our JI subsystem is storing too many methods. Specifically, it stores methods of the same name, argument types, and return type from both parent and child class, even though only the child class method will ever be callable (due to Java virtual/interface dispatch). Here's the example from that bug, calling StringBuilder.append with a Java String and a Java float:
multiple Java methods for arguments (Java::JavaLang::String), using first: public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(java.lang.String) public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(java.lang.String) public java.lang.StringBuilder java.lang.StringBuilder.append(java.lang.String) public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(java.lang.CharSequence) public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(java.lang.Object) public java.lang.Appendable java.lang.AbstractStringBuilder.append(java.lang.CharSequence) throws java.io.IOException public java.lang.Appendable java.lang.StringBuilder.append(java.lang.CharSequence) throws java.io.IOException public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(java.lang.Object) public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(java.lang.CharSequence) public java.lang.StringBuilder java.lang.StringBuilder.append(java.lang.CharSequence) public java.lang.StringBuilder java.lang.StringBuilder.append(java.lang.Object) multiple Java methods for arguments (Java::JavaLang::Float), using first: public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(float) public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(double) public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(float) public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(double) public java.lang.StringBuilder java.lang.StringBuilder.append(double) public java.lang.StringBuilder java.lang.StringBuilder.append(float) public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(java.lang.Object) public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(char) public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(int) public java.lang.AbstractStringBuilder java.lang.AbstractStringBuilder.append(long) public java.lang.Appendable java.lang.AbstractStringBuilder.append(char) throws java.io.IOException public java.lang.Appendable java.lang.StringBuilder.append(char) throws java.io.IOException public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(java.lang.Object) public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(char) public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(int) public java.lang.AbstractStringBuilder java.lang.StringBuilder.append(long) public java.lang.StringBuilder java.lang.StringBuilder.append(java.lang.Object) public java.lang.StringBuilder java.lang.StringBuilder.append(long) public java.lang.StringBuilder java.lang.StringBuilder.append(int) public java.lang.StringBuilder java.lang.StringBuilder.append(char)
These extra methods are likely increasing the size of our JI subsystem as well as adding to the complexity of method dispatch (at least for the first time through, since we cache the best hit). We should reduce the set of methods for a given name + arity to only those that could actually be dispatched given parent/child overriding.