Joel, Thank you for the review.
Actually, that is a very good question. We will be adding the test case for this one to our vm side defmeth.PrivateMethodsTest, because you have to create a classfile since private methods in interfaces are not supported by javac, they are for internal use for Lambda support. So it was decided to not try to add them to the java reflection tests. Good question - I brought this up once with Tristan and Amy who were writing reflection tests for lambda. I will ask again about reflection coverage for invoking a method more than 15 times. thanks, Karen On Oct 10, 2013, at 9:02 AM, Joel Borggren-Franck wrote: > Hi Karen, > > I agree with the others, the code looks good though I like Paul's > suggestion. > > Silly question perhaps, do you know if we have good test coverage on > actually reflectively invoking a Method more than 15 times? > > cheers > /Joel > > On 2013-10-09, Karen Kinnear wrote: >> >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >> >> Summary: >> Reflection generates code dynamically to speed up reflection processing >> after startup. The first >> 15 runs of a reflection call use the vm code path, after that we use the >> generated code path, which >> needs to use invokespecial on private methods in interfaces. >> >> Tested: >> Test attached to the bug >> >> Also - all the 8011311 private method testing was run with this in the build: >> Robert Field's TypeTest >> 8025475 test >> defmeth privatemethodstest with reflection >> John Rose's intfbug >> jtreg: java.util, java.lang >> jck vm, lang >> >> thanks, >> Karen >> >>
