4

Does it make sense to recompile a project with a new (java 11) target version from a performance perspective if it will be run on a java 11 while source code will remain the same (java 8)? 

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.1</version>
    <configuration>
      <source>11</source>
      <target>11</target>
    </configuration>
  </plugin>

What are pitfalls to run java 8 bytecode on a newer JVM?

Update:

Code optimizer is one of the phases of compilation phase, where:

  • It helps you to establish a trade-off between execution and compilation speed
  • Improves the running time of the target program
  • Generates streamlined code still in intermediate representation
  • Removing unreachable code and getting rid of unused variables
  • Removing statements which are not altered from the loop
  • etc

read more: https://www.guru99.com/compiler-design-phases-of-compiler.html

So, I wonder if it's a big difference between different compilers (benchmarks), would be nice to have a full list of all optimization happens on a compilation phase

Serge
  • 2,574
  • 18
  • 26

1 Answers1

3

No, the javac compiler doesn't do much optimization as JIT is responsible for most optimizations during runtime, so you'd be getting pretty identical bytecode. Except the class file would be marked as Java 11, so you wouldn't be able to run it on a lower version.

Java is backwards compatible, so running Java 8 bytecode on newer versions is nothing special.

Of course running Java 8 bytecode on a newer JVM allows (possible) improved dynamic optimizations in the JIT to be used, so you're more likely to get improved performance just using a later JVM without any additional compilation.

As Johannes' video shows there's always interest to optimize Strings for memory and speed, since they're the most commonly used objects in Java projects. However it's still a microbenchmark, and most of the differences come from code compiled and run with Java 11 vs. code compiled and run with Java 8.

I tried to find sources that would address the recompilation, but couldn't find anything with a quick peek. So until there's evidence that non-microbenchmarks would benefit (realistic, not theoretical) from recompilation to Java 11 bytecode, I'll classify it under "Performance Voodoo".

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • 2
    No, you won't get identical bytecode. As I said in the comments, Java 9 changed how string concatenation is compiled (it now uses invokedynamic). – Johannes Kuhn Oct 08 '19 at 13:07
  • 1
    @JohannesKuhn I said "pretty identical". It certainly doesn't provide you with significant performance improvements. – Kayaman Oct 08 '19 at 13:08
  • See [this talk](https://www.youtube.com/watch?v=z3yu1kjtcok) for a discussion about it. – Johannes Kuhn Oct 08 '19 at 13:36
  • @JohannesKuhn any particular point? I don't feel like watching 45 minutes of `String` video, especially when I don't know why I'm given the link. Are you saying the video encourages people to recompile for Java 9? – Kayaman Oct 08 '19 at 13:39
  • First row is the the usual `foo + "bar + baz"` string concat. Last column is, well Java 11. As you can see, in this case the performance is better. I highly recommend watching the entire talk. – Johannes Kuhn Oct 08 '19 at 14:38
  • @JohannesKuhn I understand the video perfectly. I know there are many improvements especially regarding Strings, but it does not make sense to **recompile** your program. Most of String handling is done in libraries, not your code, so to get any advantage from recompiling, you'd need to have a program that does mainly String handling and doesn't use libraries. Otherwise there are plenty of improvements you get just by **running** with a Java 11 JVM. – Kayaman Oct 08 '19 at 14:58
  • I agree. But I don't know what kind of application OP has. It might be a string based application, or it might not. I don't know. In the future `String.format` and non-capturing lambdas will be compiled differently (and more lambdas will be considered non-capturing - see the talk "Below the fold" from Brian Goetz). YMMV, but there might be a good reason to recompile the code. – Johannes Kuhn Oct 08 '19 at 15:29
  • I think this raises an interesting question. Library developers want their libraries to be widely compatible so java 8 is chosen since trying to produce libraries for multiple jdk's is not convenient in java. I imagine 99% of the libraries in maven central etc are compiled for java 8. Surely there will come a time when it is worthwhile recompiling them..? – Solubris Oct 03 '21 at 01:34
  • @Solubris "surely" is conjecture. Performance is a measuring game, and libraries evolve so newer versions (and newer libraries) drop Java 8 support anyway. There are **many** things to optimize before recompiling libraries would become worth considering, unless a library is identified as a performance hotspot that should be fixed with recompiling, rather than improving the library code in a different way. – Kayaman Oct 03 '21 at 17:37