Inflation System Properties
阿新 • • 發佈：2018-01-01
source isa dac rom cti ots points pure oppo
There are a ton of good resources out on the net that explain inflation in detail and why we do it. I won‘t try to duplicate the level of detail of those efforts here. But just to recap:
There are two ways for Java reflection to invoke a method (or constructor) of a class: JNI or pure-Java. JNI is slow to execute (mostly because of the transition overhead from Java to JNI and back), but it incurs zero initial cost because we do not need to generate anything; a generic accessor implementation is already built-in. The pure-Java solution runs much faster (no JNI overhead), but has a high initial cost because we need to generate custom bytecode at runtime for each method we need to call. So ideally we want to only generate pure-Java implementations for methods that will be called many times. Inflation is the technique the Java runtime uses to try and achieve this goal. We initially use JNI by default, but later generate pure-Java versions only for accessors that are invoked more times than a certain threshold. If you think this sounds similar to HotSpot method compilation (interpreter before JIT) or tiered compilation (c1 before c2), you‘ve got the right idea.
This brings us to our two system properties that influence inflation behavior:
sun.reflect.inflationThreshold
This integer specifies the number of times a method will be accessed via the JNI implementation before a custom pure-Java accessor is generated. (default: 15)
sun.reflect.noInflation
This boolean will disable inflation (the default use of JNI before the threshold is reached). In other words, if this is set to true, we immediately skip to generating a pure-Java implementation on the first access. (default: false)
There are a few points I would like to make about the behavior of these two properties:
1. noInflation does NOT disable the generation of pure-Java accessors, it disables use of the JNI accessor. This behavior is the exact opposite of what many users assume based on the name. In this case, "inflation" does not refer to the act of generating a pure-Java accessor, it refers to the 2-stage process of using JNI to try and avoid the overhead of generating a pure-Java accessor for a method that may only be called a handful of times. Setting this to true means you don‘t want to use JNI accessors at all, and always generate pure-Java accessors.
2. Setting inflationThreshold to 0 does NOT disable the generation of pure-Java accessors. In fact, it has almost the exact opposite effect! If you set this property to 0, on the first access, the runtime will determine that the threshold has already been crossed and will generate a pure-Java accessor (which will be used starting from the next invocation). Apparently, IBM‘s JDK interprets this property differently, but on both of Oracle‘s JDKs (OracleJDK and JRockit) and OpenJDK, 0 will not disable generation of Java accessors, it will almost guarantee it. (Note that because the first invocation will still use the JNI accessor, any value of 0 or less will behave the same as a setting of 1. If you want to generate and use a pure-Java accessor from the very first invocation, setting noInflation to true is the correct way.)
So there is no way to completely disable the generation of pure-Java accessors using these two system properties. The closest we can get is to set the value of inflationThreshold to some really large value. This property is a Java int, so why not use Integer.MAX_VALUE ((2^31)-1)?
$ java -Dsun.reflect.inflationThreshold=2147483647 MyApp
This should hopefully meet the needs for anyone looking to prevent continuous runtime generation of pure-Java accessors.
For those of you interested in all of the (not really so) gory details, the following source files (from OpenJDK) correspond to most of the behavior I have described above:
jdk/src/share/classes/sun/reflect/ReflectionFactory.java
jdk/src/share/classes/sun/reflect/NativeMethodAccessorImpl.java
jdk/src/share/classes/sun/reflect/DelegatingMethodAccessorImpl.java
jdk/src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
jdk/src/share/classes/sun/reflect/DelegatingConstructorAccessorImpl.java
As with anything undocumented, you should not rely on the behavior of these options (or even their continued existence). The idea is you should not normally need to set these properties or even understand what inflation is; it should be transparent and "just work" right out of the box. The inflation implementation could change at any point in the future without notice. But for now, hopefully this post will help prevent some of the confusion out there.
https://blogs.oracle.com/buck/inflation-system-properties
I wanted to write a quick post about the two inflation-related system properties: sun.reflect.inflationThreshold and sun.reflect.noInflation. There seems to be a lot of confusion on Oracle‘s forums (and the rest of the net) regarding their behavior. Since neither of these properties is officially documented by us, I thought an informal explanation here might help some people.
There are a ton of good resources out on the net that explain inflation in detail and why we do it. I won‘t try to duplicate the level of detail of those efforts here. But just to recap:
There are two ways for Java reflection to invoke a method (or constructor) of a class: JNI or pure-Java. JNI is slow to execute (mostly because of the transition overhead from Java to JNI and back), but it incurs zero initial cost because we do not need to generate anything; a generic accessor implementation is already built-in. The pure-Java solution runs much faster (no JNI overhead), but has a high initial cost because we need to generate custom bytecode at runtime for each method we need to call. So ideally we want to only generate pure-Java implementations for methods that will be called many times. Inflation is the technique the Java runtime uses to try and achieve this goal. We initially use JNI by default, but later generate pure-Java versions only for accessors that are invoked more times than a certain threshold. If you think this sounds similar to HotSpot method compilation (interpreter before JIT) or tiered compilation (c1 before c2), you‘ve got the right idea.
This brings us to our two system properties that influence inflation behavior:
sun.reflect.inflationThreshold
This integer specifies the number of times a method will be accessed via the JNI implementation before a custom pure-Java accessor is generated. (default: 15)
sun.reflect.noInflation
This boolean will disable inflation (the default use of JNI before the threshold is reached). In other words, if this is set to true, we immediately skip to generating a pure-Java implementation on the first access. (default: false)
There are a few points I would like to make about the behavior of these two properties:
1. noInflation does NOT disable the generation of pure-Java accessors, it disables use of the JNI accessor. This behavior is the exact opposite of what many users assume based on the name. In this case, "inflation" does not refer to the act of generating a pure-Java accessor, it refers to the 2-stage process of using JNI to try and avoid the overhead of generating a pure-Java accessor for a method that may only be called a handful of times. Setting this to true means you don‘t want to use JNI accessors at all, and always generate pure-Java accessors.
2. Setting inflationThreshold to 0 does NOT disable the generation of pure-Java accessors. In fact, it has almost the exact opposite effect! If you set this property to 0, on the first access, the runtime will determine that the threshold has already been crossed and will generate a pure-Java accessor (which will be used starting from the next invocation). Apparently, IBM‘s JDK interprets this property differently, but on both of Oracle‘s JDKs (OracleJDK and JRockit) and OpenJDK, 0 will not disable generation of Java accessors, it will almost guarantee it. (Note that because the first invocation will still use the JNI accessor, any value of 0 or less will behave the same as a setting of 1. If you want to generate and use a pure-Java accessor from the very first invocation, setting noInflation to true is the correct way.)
So there is no way to completely disable the generation of pure-Java accessors using these two system properties. The closest we can get is to set the value of inflationThreshold to some really large value. This property is a Java int, so why not use Integer.MAX_VALUE ((2^31)-1)?
$ java -Dsun.reflect.inflationThreshold=2147483647 MyApp
This should hopefully meet the needs for anyone looking to prevent continuous runtime generation of pure-Java accessors.
For those of you interested in all of the (not really so) gory details, the following source files (from OpenJDK) correspond to most of the behavior I have described above:
jdk/src/share/classes/sun/reflect/ReflectionFactory.java
jdk/src/share/classes/sun/reflect/NativeMethodAccessorImpl.java
jdk/src/share/classes/sun/reflect/DelegatingMethodAccessorImpl.java
jdk/src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java
jdk/src/share/classes/sun/reflect/DelegatingConstructorAccessorImpl.java
As with anything undocumented, you should not rely on the behavior of these options (or even their continued existence). The idea is you should not normally need to set these properties or even understand what inflation is; it should be transparent and "just work" right out of the box. The inflation implementation could change at any point in the future without notice. But for now, hopefully this post will help prevent some of the confusion out there.
Inflation System Properties