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

[Peter Levart]

On 10/11/2013 06:56 AM, David Holmes wrote:
> Karen,
>
> You can set the system property sun.reflect.inflationThreshold=N to 
> change the magic value from 15. That makes testing easier.

Or, alternatively, you can set sun.reflect.noInflation=true, which 
generates code straight away, so that even 1st invocation goes throught 
the generated accessor. Contrasting this with 
sun.reflect.inflationThreshold=0 where accessor is generated on 1st 
invocation, but 1st invocation still goes via native accessor.

Regards, Peter

>
> 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
>>>>
>>>>
>>