will this code be inlined?

[Tudor Raneti]

I’ve refactored my authorization code into an util method so I have a common place for future modification and also it’s less lines to write/paste. I’ve made it final so it is inlined by the compiler (I hope). Will it, given the code below? I have doubts because of the parameters, though the compiler should be able to inline the code if it was taught to

public final class Util {
...
public static final boolean isUserAuthorizedFor(String authorization,
			Window window) {
		Subject subject = SecurityUtils.getSubject();
		if (subject.isAuthenticated()) {
			if (!subject.isPermitted(authorization)) {
				window.showNotification(Lang.getMessage("PLEASE_BUY_SERVICE"));
				return false;
			}
		} else {
			window.showNotification(Lang.getMessage("PLEASE_REGISTER"));
			return false;
		}
		return true;
	}

@Override
	public void buttonClick(ClickEvent event) {
	if (!Util.isUserAuthorizedFor("generation", getWindow()))
					return; 

[Jeff Verdegan]

By "the compiler", if you mean javac, which converts Java source code to bytecode, then no, it will not. That compiler does little or no optimization.

The hotspot compiler in the JVM has various optimization techniques that it applies on code that has been run many times. (I seem to remember hearing 10,000 as a tipping point, but don't quote me on that.) In general, however, we can't predict which code it will optimize or which optimizations it will apply.

It seems unlikely that it would inline that code, and there would be no benefit to doing so.

When you're writing Java code, do not write it with the aim of it being inlined or of any other optimizations being applied. That's hotspot's job. Trying to apply those kinds of microoptimzations to Java code is pointless and counterproductive. You should write dumb code that it clear and easy to understand and maintain.

[Tudor Raneti]

It seems unlikely that it would inline that code, and there would be no benefit to doing so.

Pushing stuff on the stack takes extra CPU cycles.
Also, this code bit is checked almost on every other client request, and, if there's 100 clients logged in at one time... it's 100 times the overhead if the code doesn't get inlined.

All that the hotspot compiler need to do is take the parameters of the method and make an assignment like:
String authorization = ...
Window window = ...
then inline the rest.

It's possible to do at javac time, and I seen this HERE:

-O
Directs the compiler to try to generate faster code by inlining static, final and private methods. This option may slow down compilation, make larger class files, and/or make it difficult to debug. -O implicitly turns on -depend and turns off -g.

This option informs the compiler that all generated class files are guaranteed to be delivered and upgraded as a unit, enabling optimizations that may otherwise break binary compatibility. Use this option with discretion.

The Java Language Specification section 13.4.21 describes situations in which it is legal to use a java compiler to inline methods. The compiler will only optimize code for which source is available during the compilation, so the only .java files discoverable by the compiler should be for classes intended to be delivered or upgraded as a unit. In particular, ensure that no sources for other classes are accessible on CLASSPATH, keeping in mind that the present working directory, `.', is appended to CLASSPATH.

To ensure that a product is able to run on 1.1 as well as future binary-compatible java virtual machines, one must ensure that any sources for JDK 1.1 classes are never available along CLASSPATH while using -O.

Trying to tell if it did or did not ATM, perhaps observing class file length?

[Jeff Verdegan]

Tudor Raneti wrote:

It seems unlikely that it would inline that code, and there would be no benefit to doing so.

Pushing stuff on the stack takes extra CPU cycles.

Seriously, that kind of microoptimization has no place in Java code. There's plenty of literature to support this. I linked you to one of the seminal articles on the subject.

Also, this code bit is checked almost on every other client request

Yes, client request which equals I/O which will dwarf any stack allocation into insignificance.

, and, if there's 100 clients logged in at one time... it's 100 times the overhead if the code doesn't get inlined.

100 stack frames is nothing, especially on a server class machine.

Here's some code I used to time method invocations. I added the Child and Grandchild classes and the varargs just now, to add the overhead of dispatch lookup, but I didn't adjust the calculations for method calls, so I'm actually showing worse performance than I'm getting. On my laptop, I get over 14,000,000 method calls per sec., and that's not counting a couple of calls to nanoTime(), String.valueOf(), and Set.add() every time around.

package scratch;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

public class MethodCallsPerSec {

    private double dummy;

    public static void main(String [] args) {
        List<Integer> list = new ArrayList<Integer>();
        for (int i = 0; i < 10 * 1000; i++) {
            list.add(i);
        }

        double[] arr = new double[list.size()];
        for (int i = 0; i < arr.length; i++) {
            arr[i] = 1.0 / list.get(i);
        }

        String s1 = list.toString();
        String s2 = Arrays.toString(arr);

        long start;
        long end;
        long elapsed;
        int times = 100 * 1000 * 1000;

        MethodCallsPerSec s = new Grandchild();

        start = System.nanoTime();
        for (int i = 0 ; i < times ; i++) {
            s.foo(list, arr, s1, s2, "a", String.valueOf(System.nanoTime()), "b", String.valueOf(System.nanoTime()), "c");
        }
        end = System.nanoTime();
        elapsed = end - start;

        System.out.printf("At least %,d method calls took %,d nanos%n", 8L * times, elapsed);
        System.out.printf("Which is at least %,d calls / sec%n", 8L * 1000L * 1000L * 1000L * times / elapsed);
        System.out.printf("Or at most %e sec / call%n", ((double)elapsed) / (8L * 1000L * 1000L * 1000L * times));
    }

    public void foo(List<Integer> list, double[] arr, String s1, String s2, String... args) {
        int tmp = (int)System.nanoTime() & 0x7FFFFFFF;
        dummy =  list.get(tmp % list.size()) + arr[tmp % arr.length] + s1.charAt(tmp % s1.length()) + s2.charAt(tmp % s2.length());
    }
}

class Child extends MethodCallsPerSec {
    @Override
    public void foo(List<Integer> list, double[] arr, String s1, String s2, String... args) {
        super.foo(list, arr, s1, s2, args);
        Set<String> set = new HashSet<String>();
        for (int i = 0 ; i < args.length; i++) {
            set.add(args[i]);
        }
    }
}

class Grandchild extends Child {
    @Override
    public void foo(List<Integer> list, double[] arr, String s1, String s2, String... args) {
        super.foo(list, arr, s1, s2, args);
        Set<String> set = new HashSet<String>();
        for (int i = args.length - 1 ; i >= 0; i--) {
            set.add(args[i]);
        }
    }
}


At least 800,000,000 method calls took 56,437,251,900 nanos
Which is at least 14,175,034 calls / sec
Or at most 7.054656e-08 sec / call

[Jeff Verdegan]

Tudor Raneti wrote:

It's possible to do at javac time, and I seen this HERE:

-O
Directs the compiler to try to generate faster code by inlining static, final and private methods. This option may slow down compilation, make larger class files, and/or make it difficult to debug. -O implicitly turns on -depend and turns off -g.

This option informs the compiler that all generated class files are guaranteed to be delivered and upgraded as a unit, enabling optimizations that may otherwise break binary compatibility. Use this option with discretion.

The Java Language Specification section 13.4.21 describes situations in which it is legal to use a java compiler to inline methods. The compiler will only optimize code for which source is available during the compilation, so the only .java files discoverable by the compiler should be for classes intended to be delivered or upgraded as a unit. In particular, ensure that no sources for other classes are accessible on CLASSPATH, keeping in mind that the present working directory, `.', is appended to CLASSPATH.

To ensure that a product is able to run on 1.1 as well as future binary-compatible java virtual machines, one must ensure that any sources for JDK 1.1 classes are never available along CLASSPATH while using -O.

Trying to tell if it did or did not ATM, perhaps observing class file length?

That document is very old, and as it points out, javac only inlines certain methods. I don't know if it even bothers doing that any more. All the real optimization is done in hotspot, and, as the article I linked you to points out, you don't need to go out of your way to help it, other than by writing dumb code.

[Tudor Raneti]

Found the newer one HERE
(though it's non-trivial to give the flag on Eclipse, must do an Ant build for that):

optimize Indicates whether source should be compiled with optimization; defaults to off. Note that this flag is just ignored by Sun's javac starting with JDK 1.3 (since compile-time optimization is unnecessary).

In latest javac the option seems to be missing entirely

It would seem that optimising this isn't really necessary, still... it's only one final keyword and I was mainly concerned if it does inline the code, which I can't tell and too lazy to make up an experiment ATM (isn't worth it)

On my work machine I only get:

At least 8,000,000 method calls took 1,772,522,100 nanos
Which is at least 4,513,342 calls / sec
Or at most 2.215653e-07 sec / call

And my lappy which will run the webapp is 2 to 3 times slower
, which still seems more than enough

Thanks for the help

[Matthew Brown]

Static methods are (almost) implicitly static anyway. The "final" only has an effect on method hiding, and that's completely resolved at compile time. So I'd be very surprised if final had an optimising effect in this case.

For non-static methods, it's often a good idea to make a method final if the intention is that it should never be overridden anyway - you don't need to consider optimisation for that. (Not that I usually bother with this, but I'm vaguely aware that I should).

[Jeff Verdegan]

Tudor Raneti wrote:
It would seem that optimising this isn't really necessary

Correct. The kinds of optimizations that a C or assembly programmer would do as a matter of course simply are not useful or relevant in the context of Java code. Those are done automatically by hotspot at runtime.

What we do for performance when writing Java code is to use the appropriate architecture, design, algorithms, and data structures. There may still be room for smaller optimizations, but it's highly unlikely we'll be able to predict where they'll be needed. So we test under load, and if it doesn't meet our performance requirements, we use a profiler to look for bottlenecks. That way we only optimize code that has been measured to be problematic, and we only leave our optimizations in place if further measurements show that they had a significant positive impact.

, still... it's only one final keyword

Which we would provide if it made sense from a design perspective, but not just to try to get the method inlined.

Note also that hotspot can optimize chunks of code more fine-grained than just the method level. So even if the whole method can't be inlined, hotspot may decide to apply various optimizations to various pieces of it.

and I was mainly concerned if it does inline the code, which I can't tell and too lazy to make up an experiment ATM (isn't worth it)

Since the JVM spec doesn't dictate what optimizations will be performed in which circumstances, and since nearly every new release of the JVM includes hotspot improvements, about the only way you can predict is to look at the source code for the particular version of the particular JVM implementation that you're using today.

Thanks for the help

You're very welcome!

[Pat Farrell]

20+ years ago, there was a lot of interest in optimizing compilers. These were especially critical for RISC and LIW processors. The techniques were well known and included inlining and loop unrolling.

Modern languages, and modern computer science research, no longer approach the issue that way. Rather, the runtime system (JVM for Java) instruments
the running code and changes it on the fly. It will automatically and invisibly do things like inlining and loop unrolling.

It is counter productive to waste the programmer's time with this. Let the JVM do its job. It does a better job that you can, anyway.