-4

Working on migrating our application to Java 7. We see runtime performance issues compiling Java 6 bytecode with Java 7. Is that expected? What are the downsides/benefits of doing that?

We have a web application that has a SOAP interface. In our regression testing we shoot SOAP messages at it and get SOAP messages back. We use Groovy to help manage this testing.

To be more explicit, we are compiling with

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

with a Java 7 SDK. Doesn't this compile java 6 byte code? (With Java 7)

Some examples of things I'm looking for

Given that HashMaps in jdk1.6 and above cause problems with multi=threading, how should I fix my code

https://www.servoy.com/forum/viewtopic.php?f=6&t=19140

For our testing service we simulate users hitting our web service. Reducing the number of threads to 8 instead of 20 in our tests significantly decreased overall runtime. This was based on the HashMap article above. Can anyone else see another reason that there would be decreased performance with multithreading? In java 6, we ran with 20 threads and it was faster.

Community
  • 1
  • 1
Carlos Bribiescas
  • 4,197
  • 9
  • 35
  • 66
  • 2
    You'll have to be more specific as to what your code does and what performs differently for us to be of much help. – Jeffrey Bosboom Oct 04 '14 at 00:28
  • http://stackoverflow.com/posts/26188412/revisions @spe – jmj Oct 04 '14 at 00:29
  • @EJP: I _think_ he means he has Java 6-level source code that runs more slowly when compiled with a Java 7 javac and run on a Java 7 JVM. – Jeffrey Bosboom Oct 04 '14 at 00:32
  • @JeffreyBosboom Yes. – Carlos Bribiescas Oct 04 '14 at 00:34
  • 6
    I suspect your question is poorly worded. The question sounds like you're saying "Using javac -target 1.6 with JDK 7 produces bytecode that is less efficient than using javac from JDK 6 when the output is run on the same JVM", which while possible is very unlikely. It sounds like what you're really saying is "Using a Java 7 runtime to run our application (written in Java 6) is less efficient than using a Java 6 runtime". If the latter is what you're saying, you're unlikely to get a good answer unless you use a profiler to pinpoint what exactly is slower. – Brett Kail Oct 04 '14 at 00:44
  • We've not tried compiling with Java 6 and running on Java 7. We're trying Java 6 byte code compiled with Java 7, run on Java 7. You're saying thats unlikely to be a cause? Should we try running that on Java 6 JVM? More importantly, if I understood your comment correctly, can you recommend an article that explains why thats the case? – Carlos Bribiescas Oct 04 '14 at 00:47
  • You're saying "compiling Java 6 bytecode with Java 7", but this makes no sense. You have some source code, *compile* it with *what* version of Java into bytecode and *run* the bytecode with *what* version of Java? The JVM runs the bytecode and compiles it, too, but nobody expresses it this way. If you **add the command lines**, everything will get clearer. However, you still have to localize the slowest part somehow, as for sure there's no "JDK7 global performance regression". I guess, your question gets closed soon, but add the details and it'll get reopened. – maaartinus Oct 04 '14 at 02:05
  • hah, yes, if there was a "global slowdown factor" then i doubt java 7 would be released. I am asking a vague question, that is a real task I have. but as people have commented I've done my best to improve the question... – Carlos Bribiescas Oct 04 '14 at 02:26
  • 1
    Are you asking if java 6 is backwards compatible with java 7? Because it is, of course. What I don't understand is why you are targeting 1.6 when you've clearly stated that you're transitioning to 1.7 – arkon Oct 04 '14 at 02:33
  • Good point. Seemed like a middle step between the two because it was presented to me as such by people more experienced than myself. Let me try removing that – Carlos Bribiescas Oct 04 '14 at 02:36
  • I'm afraid, this is still not enough. Your application does a million things and something you're doing a lot might have got slower. Profile you app with both Java 6 and 7 and look at the differences. Post it here. Use some debugging flags, e.g., print compilation and GC and whatever. Try to restrict the app to doing fewer things... – maaartinus Oct 04 '14 at 06:45

1 Answers1

1

We see runtime performance issues compiling Java 6 bytecode with Java 7. Is that expected?

No. It is not expected. It is possible ... but I wouldn't have predicted it, and I can't think of an obvious explanation.

What are the downsides/benefits of doing that?

I can think of no real benefits to your problem (migration) of compiling code using Java 7 tools and setting to "-target" to "1.6". I would go straight to compiling for the Java 7 platform.

Certainly, there is nothing to be gained from trying to figure out why the code apparently runs slower. It might be a real effect, or an illusion; e.g. an artefact of the way you are doing your benchmarking / performance measurement. But either way, it doesn't tell you anything about what will happen if you compile for Java 7 and run on Java 7 ... which is where you are trying to get to.

In general, you would not expect performance to be slower in a newer release of Java. However, there are factors that could cause performance characteristics to change. For example:

  • Changes in the JIT compiler might in theory cause certain atypical applications to run slower.

  • Changes in JIT compilation strategy might result in code being JIT compiled later ... which could affect performance during startup / warmup. (A benchmarking should be designed to compensate for that ...)

  • Changes in heap organization / garbage collection algorithms could require tuning / retuning.

And so on.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216