Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Study of Various Java Compilers  RSS feed

 
Nick Heudecker
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi,

Does anyone know if there is a fairly recent study of the performance impacts on the bytecode produced by different Java compilers? For instance: jikes v. javac v. TurboJ.

Finally, if such a study does not exist and I have to create one myself, what would you (the community) like to see in such a study?

Thanks for your time.
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are a number of established JVM benchmarks including CaffineMark, VolcanoMark, SpecJVM, SciMark, and JMark. They may also have compilation metric tools.
What do you propose to measure, size? It seems to make the most sense to evaluate compiler/JVM pairs, rather than just compilers, because different JVMs may treat different byte code differently--I don't know enough about JITs and related JVM topics to get into more detail.
--Mark
hershey@vaultus.com
 
Peter Haggar
author
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most Java compilers don't produce very good bytecode. Also, they optimize little to nothing. (I have been told that Sybase has a compiler that performs bytecode level optimization but I have not verified it yet.) Virtually all of the optimiztion is being done at runtime with JITs and Hotspot.
If you were to do a study, one problem you would have is that one set of bytecode can execute at different speeds on different JVM/JIT combinations. Some JITs (and Hotspot) are fairly advanced making measurements not impossible, but difficult. If you were to look at compilers, I would be interested in how small a .class file they produce and how much bytecode level optimization they do. Anyone running Java code without a JIT would be very interested in this.
Peter Haggar
------------------
author of: Practical Java
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, Peter Hagger! (I loved your JavaOne talk and your book.)
One question I've always wondered about was shooting yourself in the foot with optimization tools. We've been using obfuscators to optimize the bytecode (first dashO, and then we switched to SourceGuard). I'm wondering if they ever do any optimizations which prevent the JVM from doing other (possibly better) optimizations.
(Of course, for our client code, which runs under J2ME, I would suspect the kVMs aren't as sophisticated, and can't do as much in the way of optimizations.)
--Mark
hershey@vaultus.com
 
Nick Heudecker
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for all of your feedback. When I have time I do plan to perform a study on compiler/JVM/JIT performance. Of course, it'll probably take me until mid-2005 to get it done.


Thanks again.
 
Peter Haggar
author
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Herschberg:
One question I've always wondered about was shooting yourself in the foot with optimization tools. We've been using obfuscators to optimize the bytecode (first dashO, and then we switched to SourceGuard). I'm wondering if they ever do any optimizations which prevent the JVM from doing other (possibly better) optimizations.

From what I have seen, these tools do mostly size optimization. They reduce the .class file size as much as they can. They also do some bytecode level optimizations, but the last time I looked they didn't seem to be too aggressive. They are probably better now though.
That said, bytecode optimizers can cause trouble if the JIT or Hotspot is relying heavily on bytecode sequence idioms. Most compilers generate specific bytecode sequences for common Java source code fragments. A runtime optimizer can find these and eliminate some of the stack semantics generating more efficient code.
I wouldn't think that a good JIT or Hotspot would be relying heavily on idiom recognition for its optimizations though.
Peter Haggar
------------------
author of: Practical Java
 
Jack Shirazi
Author
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So far, I've found only one optimization that counters HotSpot's optimizations, and that was loop unrolling (which I did manually but could easily be done by an optimizing compiler).
The details are in my book, but basically I found that HotSpot could run slower if I manually unrolled a loop, while all the other VMs I tested were definitely faster with the loop unrolled.
The observation was not so straightforward though, because HotSpot's relative speed depended on the data - the particular example was reading and processing text lines - and HotSpot was faster after loop unrolling for some sets of the data, but slower for other datasets. Which is a pain.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!