I was reading through Java-The Complete Reference,and then I encountered this statement which says that-
Methods declared as final can sometimes provide a performance enhancement:
Reason given is-
The compiler is free to inline calls to them because it “knows” they
will not be overridden by a subclass.
When a small final method is called, often the Java compiler can copy
the bytecode
for the subroutine directly inline with the compiled code of the calling method,
thus eliminating the costly overhead associated with a method call.
Inlining is only an option with final methods.
I am not able to understand the second point.Can somebody please explain?What exactly is Inlining?
Related
As far as I understand JShell statements are wrapped in synthetic classes when the code snippet is evaluated the first time. This is documented in the JEP-222.
Can I conclude that excluding the first evaluation of the snippet (let's say a method definition and call) that triggers generation of synthetic class, methods and variables, the following calls (for instance calling the same method in a loop) to the same code snippet will perform as fast as normal java code and could even be compiled by the Java compiler at runtime if the snippet becomes "hot"
How does method/field visibility impact on method inlining in Java?
The case I have in mind is something like a public getter for a private field:
private Thing blah;
public Thing getBlah() {
return blah;
}
There are several issues that arise here.
For one, does the Java compiler itself do any inlining? This question seems to be answered variously, with some saying yes and some saying no. I don't know whether that's because it used not to do any inlining but now does, or whether it's just that some people are right and some people are wrong...
Now, if it does do some inlining, am I right in thinking that it can't possibly inline getBlah() calls? They would be an obvious place for inlining to be useful, because the method is very simple, and the overhead of invoking a method is as big as the code for the method itself. But if it got inlined by the compiler, you'd end up with bytecode that accessed a private field directly; and surely the JVM would then complain? (This would apply even if this method were static final.)
Secondly, what about the JIT compiler? As far as I can see, this problem doesn't apply when it comes to inlining at that level. Once it's producing native code, the JVM has already done its checks, and confirmed that I can invoke the method (because it's public); so it can then generate native code that inlines the call, without any visibility issues... yes?
The javac compiler (and any valid java compiler) will not and can not inline getters; think about it: You could extend a class from that class and overwrite the getter. And yes if a compiler would overzealously inline that access it would not pass the verifier (well at least it should not pass the verifier, but they don't verify everything - in java 1.3 you could even make main() private and it would still work... likewise there used to be an -O option in javac that did sometimes screw your code).
The JIT is a whole other beast; it knows (well at least nowadays) at any time if there is an overwite for a method or not. Even if a class is later loaded that overwrites the getter, it can deoptimize already JIT'd methods to refelect alterations on the inhertance tree (thats one of the optimizations AOT compilers lack the information for).
Thus it can safely inline whatever it wants. It also doesn't need to artificially uphold access modfiers, because there is no such thing in the compiled machine code and again it knows what is a vaild code transformatiom (and since getters are so common its also a low hanging fruit for the JIT to optimize).
Edit: To make it absolutely clear, above paragraphs address potentially virtual methods; specifically those that are not private, static or final. Javac could perform inlining in some cases; because it could prove that no override can exist for those. It would be a pointless undertaking in face of the fact that the JIT also does it, and it does a far better job at it.
javac does not inline methods, even as simple as getBlah() and setBlah()
As to HotSpot JVM, JIT compiler does inline all such methods unless it reaches the maximum level of inlining (-XX:MaxInlineLevel)
JIT equally treats public and private methods in terms of inlining. Access modifiers does not generally affect inlining unless some very specific cases.
Whether or not any particular Java compiler -- Oracle's, for instance -- performs any inlining is an implementation detail that you would be better off ignoring. A future generation of your chosen compiler or an alternative compiler might operate differently than the one you happen to be looking at now.
To the extent that a Java compiler did perform inlining, however, it could inline only private methods and constructors. Anything else is a candidate for access from (unknowable) other classes.
A JIT compiler, on the other hand, can do pretty much anything it wants, including inlining public methods. It is responsible for any adjustments that may be needed when new classes are loaded. Beans-style accessor methods are a particularly likely thing for a JIT to optimize, they being such a common pattern.
Has Java like other languages a directive to inline a method at compile time or at JIT time?
We have many methods that call only the super method. This make it clear that it was not forget to override the method.
For example you have override the equals methods but was use the same hashcode like super implementation. This make clear for a later developer that the hashcode method was not forget to implements. The same is also valid for setter and getter or add and remove.
But the compiler should inline this method.
The Java compiler does very few optimisations at compile time.
Instead the JIT does most of the optimisations at runtime based on how the applciation is actually used. It can inline methods, even up to two "virtual" methods.
No java does not. It's not a meaningful concept on Java.
As for the discussion of hashCode versus equals, some IDE and style checkers will warn you about mistakes like this, but I don't see that it has anything to do with 'inline'.
I don't think this can be inlined during compilation in Java, as all functions in Java are virtual, and you don't know until runtime which method is actually called, it might be the one of a subclass.
However, I don't think you need to worry about these things, because the HotSpot compiler should be pretty good at optimizing code that gets called frequently, on-the-fly, as the application is running.
Marking a method as final gives the JIT compiler a big hint as to how it can treat this method. You cannot force it to inline the method, but giving the JIT more explicit information can only help.
I'm currently writing a toy compiler targeting Java bytecode in the translation.
I would like to know if there is some kind of catalog, maybe a summary, of various simple peephole optimizations that can be made in the emitted bytecode before writing the .class file. I actually am aware of some libraries that have this functionality, but I'd like to implement that myself.
You are aware of Proguard? http://proguard.sourceforge.net/
This is a great bytecode optimizer which implements a lot of optimizations. See the FAQ for a list: http://proguard.sourceforge.net/FAQ.html
Evaluate constant expressions.
Remove unnecessary field accesses and method
calls.
Remove unnecessary branches.
Remove unnecessary comparisons and
instanceof tests.
Remove unused code
blocks.
Merge identical code blocks.
Reduce variable allocation.
Remove
write-only fields and unused method
parameters.
Inline constant fields,
method parameters, and return values.
Inline methods that are short or only
called once.
Simplify tail recursion
calls.
Merge classes and interfaces.
Make methods private, static, and
final when possible.
Make classes
static and final when possible.
Replace interfaces that have single
implementations.
Perform over 200
peephole optimizations, like
replacing ...*2 by ...<<1.
Optionally
remove logging code.
I'm sure you can further look into the source code to understand how they are implemented.
Is there a concept of inline functions in java, or its replaced something else? If there is, how is it used? I've heard that public, static and final methods are the inline functions. Can we create our own inline function?
In Java, the optimizations are usually done at the JVM level. At runtime, the JVM perform some "complicated" analysis to determine which methods to inline. It can be aggressive in inlining, and the Hotspot JVM actually can inline non-final methods.
The java compilers almost never inline any method call (the JVM does all of that at runtime). They do inline compile time constants (e.g. final static primitive values). But not methods.
For more resources:
Article: The Java HotSpot Performance Engine: Method Inlining Example
Wiki: Inlining in OpenJDK, not fully populated but contains links to useful discussions.
No, there is no inline function in java. Yes, you can use a public static method anywhere in the code when placed in a public class. The java compiler may do inline expansion on a static or final method, but that is not guaranteed.
Typically such code optimizations are done by the compiler in combination with the JVM/JIT/HotSpot for code segments used very often. Also other optimization concepts like register declaration of parameters are not known in java.
Optimizations cannot be forced by declaration in java, but done by compiler and JIT. In many other languages these declarations are often only compiler hints (you can declare more register parameters than the processor has, the rest is ignored).
Declaring java methods static, final or private are also hints for the compiler. You should use it, but no garantees. Java performance is dynamic, not static. First call to a system is always slow because of class loading. Next calls are faster, but depending on memory and runtime the most common calls are optimized withinthe running system, so a server may become faster during runtime!
Java does not provide a way to manually suggest that a method should be inlined. As #notnoop says in the comments, the inlining is typically done by the JVM at execution time.
What you said above is correct. Sometimes final methods are created as inline, but there is no other way to explicitly create an inline function in java.
Well, there are methods could be called "inline" methods in java, but depending on the jvm. After compiling, if the method's machine code is less than 35 byte, it will be transferred to a inline method right away, if the method's machine code is less than 325 byte, it could be transferred into a inline method, depending on the jvm.
Real life example:
public class Control {
public static final long EXPIRED_ON = 1386082988202l;
public static final boolean isExpired() {
return (System.currentTimeMillis() > EXPIRED_ON);
}
}
Then in other classes, I can exit if the code has expired. If I reference the EXPIRED_ON variable from another class, the constant is inline to the byte code, making it very hard to track down all places in the code that checks the expiry date. However, if the other classes invoke the isExpired() method, the actual method is called, meaning a hacker could replace the isExpired method with another which always returns false.
I agree it would be very nice to force a compiler to inline the static final method to all classes which reference it. In that case, you need not even include the Control class, as it would not be needed at runtime.
From my research, this cannot be done. Perhaps some Obfuscator tools can do this, or, you could modify your build process to edit sources before compile.
As for proving if the method from the control class is placed inline to another class during compile, try running the other class without the Control class in the classpath.
so, it seems there arent, but you can use this workaround using guava or an equivalent Function class implementation, because that class is extremely simple, ex.:
assert false : new com.google.common.base.Function<Void,String>(){
#Override public String apply(Void input) {
//your complex code go here
return "weird message";
}}.apply(null);
yes, this is dead code just to exemplify how to create a complex code block (within {}) to do something so specific that shouldnt bother us on creating any method for it, AKA inline!
Java9 has an "Ahead of time" compiler that does several optimizations at compile-time, rather than runtime, which can be seen as inlining.