RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement (original) (raw)
Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Jun 11 09:56:14 UTC 2013
- Previous message: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement
- Next message: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/
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.
- Previous message: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement
- Next message: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]