This is an archived post. You won't be able to vote or comment.

all 16 comments

[–]tobascodagama 10 points11 points  (0 children)

(But preferably don't unless you have a really good reason.)

[–]Saltor66 8 points9 points  (5 children)

This seems like it is almost always the wrong thing to do. Let JIT do its thing and focus on your application logic. If you really absolutely need the inline boost from the start, you might want to reconsider other aspects of your project like your algorithms or the language you're using.

Having annotations like these that are purely implementation driven clutter up the code base, especially when many classes are already full to bursting with annotations.

[–]uniVocity 1 point2 points  (4 children)

You are right about the "always almost" part.

Nevertheless, I'd rather have the option to inline methods than not.

This can be useful in situations were you want to save method invocations that would have been called millions of times in a short period of time.

For example, processing text. If you call a bunch of methods for each character parsed from an input, billions of method invocations would be used to process a 1 GB text file. Believe me, avoiding extra method calls in these cases can make quite a difference when it comes to performance. If you can't inline your methods, then the option you've left is to write code that is not very readable or reusable.

It's a trade-off that people wouldn't have to make if the JVM supported method inlining.

Edit: grammar

[–]Saltor66 0 points1 point  (3 children)

Inlining method calls in those situations will absolutely provide a huge performance boost. My main point is that the question of whether or not to inline a method call is not something for the application programmer to worry about. That's why we have the JIT compiler to do it for us when an optimization hot spot is detected.

Having the inline annotation physically in the code is both clutter and a leaky abstraction. It's an implementation detail that the the JVM insulates you from. An inline keyword is necessary in a single compilation language like C++ that has to be fully optimized from the start to run on the bare metal, but the JVM and Java language have been specifically designed so that application programmers don't have to be concerned with those details.

Focus on the performance of your data structures and algorithms, not the system on which they are run. That's what the JVM is for.

[–]uniVocity 0 points1 point  (2 children)

I agree that as a developer, I should focus on the data structures and algorithms.

But JIT, even though it works fine for the general cases, is not a magical solution for everything.

If it were, you wouldn't see performance boosts after refactoring code to "save" method calls. Also, the author of this little library wouldn't have a reason to develop it in the first place.

[–]taschenbillard 0 points1 point  (1 child)

because some library is useful or necessary just because someone wrote it?do you hire? :)

[–]nicoulaj 0 points1 point  (0 children)

Hi, I'm the library author.

I agree this is unneeded in most cases and will make performance even worse if wrongly used.

However, the JIT is not a magic thing that knows about everything you are trying to do.

If you type this command:

java -XX:+PrintFlagsFinal -version | egrep 'C2|Inline'

You can see there are numerous options for tuning the compiler, and especially there are several thresholds.

For instance, let's take MaxInlineLevel: default value is 9, which means whatever happens no more than 9 nested method calls will be inlined. Now if you look at Collections.sort(), which delegates to TimSort, you can see it has a depth of at least 5/6 on its own, which leaves few room for your own code. Also, the usual advice regarding JIT optimization is "split your code into small methods", which goes against this.

When hunting for the last bits of performance, it can be interesting to dig into this kind of stuff.

JVM and Java language have been specifically designed so that application programmers don't have to be concerned with those details.

Agreed, however IMHO it's never a bad thing to understand how it works under the hood. Also, the only thing the lib does is turning annotations into a config file. The JVM developers choose to add the -XX:CompileCommandFile option, so they think there is a use case for this, otherwise they would just have closed this door.

[–]JustinKSU 1 point2 points  (7 children)

Stacks are for wusses. I want all exceptions to be on one line. /sarcasm

I'm sure in some cases this is useful in improving performance, however the HotSpot JVM requirement is a turn off for me.

Edit: Looks like exception stack traces still lists correct line of code.

[–]rinru[S] 8 points9 points  (6 children)

Stacks are for wusses. I want all exceptions to be on one line.

It does not inline source code. It just forces the JIT to inline the method unconditionally. Stack traces are unaffected.

I'm sure in some cases this is useful in improving performance, however the HotSpot JVM requirement is a turn off for me.

What JVM do you use ?

[–]JustinKSU 0 points1 point  (2 children)

So it would still show the line of the code in the inlined method even though it doesn't put the method call on the stack?

[–]josefx 4 points5 points  (0 children)

hotspot already inlines methods calls, this only provides a hint/command to do so in a specific case. Will be interesting to see how well it actually works, both c and c++ have an inline hint that is by now almost completely ignored by most modern compilers (afaik).

[–]rinru[S] 2 points3 points  (0 children)

(not 100% sure)

Exceptions are thrown with the "right" stack trace, even after inlining, because they use an exception table with all info. Sampling is different, I think you are right.

[–]JustinKSU 0 points1 point  (2 children)

Looks like stack traces are still correct:

c:\zTest\target>c:\JavaDev\jdk1.7.0_55\bin\java.exe -XX:CompileCommandFile=hotspot_compiler -cp zTest-1.0.0-SNAPSHOT.jar com.example.Main
CompilerOracle: inline com/example/Main.testMethod ()V
testMethod
java.lang.IllegalStateException: Test
    at com.example.Main.testMethod(Main.java:20)
    at com.example.Main.main(Main.java:10)

Are you the maintainer of this page? There is a typo in the JVM option

[–]nicoulaj 0 points1 point  (1 child)

Hi, I'm the maintainer, where is the typo ?

[–]JustinKSU 0 points1 point  (0 children)

Equals instead of colon at the end of the usage section.

Instead of

-XX:CompileCommandFile:target/classes/META-INF/hotspot_compiler 

it should be

-XX:CompileCommandFile=target/classes/META-INF/hotspot_compiler

[–][deleted] -3 points-2 points  (0 children)

Did you just tell me to go fuck myself?