I recently came across this interesting term and searched on Net to know more about it. However the info I found is sketchy. Could someone pl. give me a somewhat detailed explanation of what this is and why is this useful?
From the info I found, it looks like this mechanism makes reflective method execution faster, at the expense of creating a lot of dynamic classes and hogging perm gen memory area, but I'm not sure about it.
Did some source code digging and coding myself to figure this out, and here's what I've found out:
Java's 'Method' class has a member variable 'methodAccessor' of type 'MethodAccessor' which is an interface with a method 'invoke', similar to Method's invoke. Methods's invoke delegates to methodAccessor's invoke.
If inflation is enabled (noInflation is false) this accessor points to an implementation which uses JNI to run this Java method (I think using api's like GetObjectClass, GetMethodID and Call*Method). This is like duel dispatching, and execution with JNI is slow due to this and other reasons. ( What makes JNI calls slow? )
After 15 executions of a method through reflection ('15' is default and can be changed) and with noInflation false, the JNI based accessor creates a class on the fly (the name is dynamically generated, e.g. say 'GeneratedMethodAccessor1') which also has the invoke method. Now, within this 'invoke' method, it casts the first 'obj' argument to its corresponding class, and then calls the target method on it. It then creates an instance of this class, and changes the methodAccessor settings such that every execution of the method henceforth is delegated to this instance instead of JNI accessor. This is called inflation.
Because this instance is of a Java class which delegates to a Java object, the delegation henceforth is a normal Java delegation. It never goes to JNI and hence saves that overhead, plus JITC can perform other optimization on it due to which it becomes efficient.
The downside is, if a lot of methods are inflated in this manner, their classes occupy permgen space and can possibly cause out of memory error.
For details, see:
http://java.sun.com/docs/books/jni/html/fldmeth.html
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html
Java Inflation is optimization of method calls made through Java Reflection API. It delegates infrequent method calls to cheap, immediately available but slow Java Native Interface and frequent method calls to fast but expensive, runtime generated method accessor.
Not sure though but read this somewhere Inflation means that for the first few runs (default 15) of a reflected method/constructor (from now on, any reference to methods applies to constructors too), it does so via JNI; the next time after that, it assembles a class file on the fly, and loads it. At that point, full JITting applies, and further calls to that reflected method has the same performance as directly calling that method
