The "accessor" can be of two types
JNI accessor is a native accessor which requires very little setup
Bytecode accessor is the "dynamic class generation" aspect of reflection
JNI accessor is a fast to setup - slow to run
this is because switching from Java context to Native context is always time consuming
Bytecode accessor is slow to setup - fast to run
slow to setup because it needs building a class and loading it through a new classloader - but faster later on as you can have JIT optimize the class for you
Initially, the JVM uses JNI accessor for reflection. After a "threshold" , these accessors are promoted to bytecode accessors. This is called INFLATION.
Excessive Reflection has a drawback : it could lead to lot of bytecode accessors being created which inturn means lot of accessor classes and classloaders - both of which take up native memory to a large extent.
If your app is seen to be creating lot of Generated*Accessor classes or
sun.reflect.DelegatingClassloaders, then you should be looking at tuning reflection and inflation.
The default threshold for inflation for IBM Java 5.0 is 15 and can be controlled through the system property
If N is 0 or less, then the accessors will never be inflated.
-Dsun.reflect.noInflation=truedisables inflation entirely but it also means that bytecode accessors are used by default. This could lead to a high native memory footprint due to reasons mentioned above.
Make sure you read this excellent dW article on Native Memory