RFR: Lambda 8026213: Reflection support for private methods in interfaces

David Holmes david.holmes at oracle.com
Fri Oct 11 04:56:23 UTC 2013


Karen,

You can set the system property sun.reflect.inflationThreshold=N to 
change the magic value from 15. That makes testing easier.

David

On 11/10/2013 12:32 AM, Karen Kinnear wrote:
> 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
>>>
>>>
>



More information about the core-libs-dev mailing list