7

I found out that the C++ compiler does so but I want to know if the Java compiler does the same since in that answer they said adding static would do so but static is different in java and C++. In my case performance would matter since am using functions that are called only once per frame in a game loop and called nowhere else, to make it more readable
In my code I have it setup up similar to this, except with many more calls

while(running)
{
    update();
    sync();
}

and then update(), render() would call more methods that call other methods

private final void update()
{
    switch(gameState)
    {
        case 0:
            updateMainMenu();
            renderMainMenu();
            break;
        case 1:
            updateInGame();
            renderInGame();
            break;
         //and so on
    }
}

private final void updateInGame()
{
    updatePlayerData();
    updateDayCycle();
    //and so on
}

private final void updatePlayerData()
{
    updateLocation();
    updateHealth();
    //and so on
}

So would the compiler inline these functions since they are only used once per frame in the same location?

If this is a bad question, plz tell me and I will remove it.

Community
  • 1
  • 1

2 Answers2

5

A Java JITC will attempt to inline any functions that appear (based on runtime statistics) to be called often enough to merit it. It doesn't matter whether the function is called in only one place or dozens of places -- each calling site is analyzed separately.

Note that the decision is based on several factors. How big the method is is one -- if there are a lot of potential inlining candidates only the most profitable will be inlined, to avoid "code bloat". But the frequency of the call (multiplied by the perceived expense of the call) is the biggest "score" factor.

One thing that will discourage inlining is obvious polymorphic calls. If a call might be polymorphic it must be "guarded" by code that will execute the original call if the arriving class is not the expected one. If statistics prove that a call is frequently polymorphic (and including all the polymorphic variants is not worthwhile) then it's likely not sufficiently profitable to inline. A static or final method is the most attractive, since it requires no guard.

Another thing that can discourage inlining (and a lot of other stuff) is, oddly enough, a failure to return from the method. If you have a method that's entered and then loops 10 million times internally without returning, the JITC never gets a chance to "swap out" the interpreted method and "swap in" the compiled one. But JITCs overcome this to a degree by using techniques for compiling only part of a method, leaving the rest interpreted.

Hot Licks
  • 47,103
  • 17
  • 93
  • 151
4

For future reference, you can view the bytecode of a .class file with javap -c MyClass to see what your compiled code looks like.

To answer your question: the Java compiler does not inline methods. The JVM, on the other hand, analyzes your code and will inline at runtime if necessary. Basically, you shouldn't worry about it -- leave it to the JVM, and it will inline if it finds it beneficial. The JVM is typically smarter than you when it comes to these things.


From http://www.oracle.com/technetwork/java/whitepaper-135217.html#method:

Method Inlining
The frequency of virtual method invocations in the Java programming language is an important optimization bottleneck. Once the Java HotSpot adaptive optimizer has gathered information during execution about program hot spots, it not only compiles the hot spot into native code, but also performs extensive method inlining on that code.

Inlining has important benefits. It dramatically reduces the dynamic frequency of method invocations, which saves the time needed to perform those method invocations. But even more importantly, inlining produces much larger blocks of code for the optimizer to work on. This creates a situation that significantly increases the effectiveness of traditional compiler optimizations, overcoming a major obstacle to increased Java programming language performance.

Inlining is synergistic with other code optimizations, because it makes them more effective. As the Java HotSpot compiler matures, the ability to operate on large, inlined blocks of code will open the door to a host of even more advanced optimizations in the future.

arshajii
  • 127,459
  • 24
  • 238
  • 287
  • Wait but does the JVM only do it when it's run? Couldnt I do it before to make the code smaller? –  Jul 24 '14 at 00:08
  • @androidmaster The compiler won't do it for you, and yes the JVM/JIT will do it at runtime. What do you mean by "smaller"? You mean source file size? – arshajii Jul 24 '14 at 00:09
  • 1
    To be purist Java Language compiler does not inline methods. Java bytecode compiler does. – Damian Leszczyński - Vash Jul 24 '14 at 00:09
  • @Vash-DamianLeszczyński This is typically what we mean by the term "Java compiler". – arshajii Jul 24 '14 at 00:10
  • Yea I meant the source file –  Jul 24 '14 at 00:10
  • @arshajii, Me too, but in this case is worth to express the difference i think. – Damian Leszczyński - Vash Jul 24 '14 at 00:11
  • @androidmaster If you're only calling a particular function from one place, then inlining it will probably not reduce the source file size by much. If you're calling it from multiple places, then inlining it will likely make the source file *larger*. – arshajii Jul 24 '14 at 00:12
  • :P well, I dont really call many of these functions from multiple places, most of them are called only once to help the code be more readable. I would like to help optimize the code as much as I can to help make it run really efficiently and be able to add even more so that even older computers/smartphones could run it smoothly, I dont want my game to be like minecraft –  Jul 24 '14 at 00:14
  • @androidmaster You really shouldn't worry about optimizations like inlining functions. It should be taken care of for you by the JVM as I indicated. – arshajii Jul 24 '14 at 00:18
  • @Vash-DamianLeszczyński There is no difference between "Java language compiler" and "Java bytecode compiler". If by the latter you mean the JVM, that's already been stated in the answer. By all means be purist but get the terminology right too. – user207421 Jul 24 '14 at 00:47
  • @EJP I disagree. What they mean is obviously compilers taking "java language (source code)" and "java bytecode" as inputs. It's perfectly logical, the only problem is that hardly anybody ever used the second term, but it's what JITC and excelsiorjet are: java bytecode to native code compilers. – maaartinus Jul 24 '14 at 01:36
  • @JPC There is. JITCs compile bytecode that can be created from Java Langage, Scala Language, Groove Language or others so called JVM languages. During execution JVM can compile the byte code multiple time using difference characteristic in way to find best machine code. The JVM is only a concept and quoted HotSpot is one of many implementation of JVM specification. – Damian Leszczyński - Vash Jul 24 '14 at 06:43
  • 2
    @arshajii I think the idea of "you shouldn't worry about things like this" is counterproductive when targeting developers. It's better to point the reader to JVM whitepapers, JDK source code references describing the algorithms used etc. We are developers, we _want_ to know how it works under the hood, and especially: we want to learn about things that can prevent things from being able to be inlined. – Per Lundberg Dec 29 '20 at 09:21