RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement

[Peter Levart]

Aleksey,

On 06/11/2013 11:56 AM, Aleksey Shipilev wrote:
> Hi Peter,
>
> On 06/11/2013 12:57 AM, Peter Levart wrote:
>> When 'sun.reflect.noCaches=true' system property is defined,
>> reflectionData() returns null. In that case, the code should cope
>> without using ReflectionData (no caching). See other uses of
>> reflectionData() (for example: in privateGetDeclaredFields())...
> Good catch. Indeed, I was deluged by newReflectionData returning null.
> Fixed.
>
>> If 'genericSignature' is cached on ReflectionData then it would be
>> consistent to also cache the derived 'genericInfo', what do you
>> think?
> "genericSignature" is off the ReflectionData now, so it makes a little
> sense to move genericInfo there. The interference of genericInfo and
> class redefinition is an interesting in itself, and I think it should be
> taken care of elsewhere (notably, when JEP-159 lands). I'm somewhat
> resistant to do this along with the performance fix.
>
>> If there was a singleton ClassRepository NONE instance, then event
>> the boolean flag wouldn't be needed.
> Oh, that's a good idea. Implemented.
>
> The new webrev is here:
>    http://cr.openjdk.java.net/~shade/8016236/webrev.02/

That's good now. I just wonder if renaming of native getGenericSignature 
-> getGenericSignature0 is still needed now that there's no
getGenericSignature non-native method in Class. Every native method 
ending with '0' has a non-native counterpart with same name (just '0' 
stripped).

Regards, Peter

>
> Testing:
>    - Linux x86_64/release builds OK
>    - Linux x86_64/release jdk/test/java/lang/reflect/ jtreg OK
>    - Microbenchmark scores are still showing the major increase
>    - Layout dumps show Reflection data is 8 bytes more (1 oop + alignment)
>
> -Aleksey.