Java Compilers can generate "platform optimized" bytecode?
Hello experts,
In my project some people want to recompile our
server (EJB!) classes on each server platform. In fact we do not have
any platfrom specific source code. However those people claim that some java compilers do platform specific optimizations (performance ?) during compilation, and the want to take profit of this.
I am very curious to find out whether this is really true?
It contradicts all I understood about Java virtual machines and bytecode.
So my question: Are there java compilers who create "platform optimized" bytecode?
[586 byte] By [
d022195] at [2007-9-27 18:31:18]
Most modern Java compilers make no real attempt to optimize bytecodes. For instance, the Java 1.3.x and later Sun compilers leave all optimization up to the HotSpot runtime compiler. You do not need to worry about what compiler or platform was used to compile your classes, the JVM itself does the real work.
The people who tell you to recompile on different platforms are incorrect. True differnt compilers (Jikes versus Sun versus IBM, etc.) may generate different bytecodes for the same Java source, but the platform itself makes no difference. And, to reiterate, the results have no real effect on performance in your case.
Look here for a good article on Java compilation and *runtime* optimization: http://www.fawcette.com/javapro/2002_10/magazine/columns/proshop/
Well yes, the code is optimised for the Java Platform.
However those people claim that some java compilers do platform specific optimizations
Even if this were true, it would be silly. The compiler doesn't know what platform the bytecode will be run on. It doesn't even know what VM the bytecode would be run on.
Compiler often DO perform platform neutral optimizations.
e.g. The two methods below will compile to the same bytecode.
static boolean foo()
{
if (true)
return true;
else
return false;
}
static boolean foo()
{
return true;
}
use javac -O-O - produces platform optimized code
> use javac -O
> -O - produces platform optimized code
I read the tool documentation of sun's java compiler:
In jdk 1.3.1 it says:
[citation:]
"Note: the -O option does nothing in the current implementation of javac and oldjavac"
In jdk 1.4 it did not find the -O option at all.
Anyway it remains still unclear if "-O" ever did operating system specific optimizations.
I would like to know most of all about compilers for HP-UX or SunOS ...
Maybe there is vendor specific documentation about this issue ...
> In my project some people want to recompile our
> server (EJB!) classes on each server platform. In fact
> we do not have
> any platfrom specific source code. However those
> people claim that some java compilers do platform
> specific optimizations (performance ?) during
> compilation, and the want to take profit of this.
Either they do not know what they are talking about or you misunderstood what they said.
> Anyway it remains still unclear if "-O" ever did
> operating system specific optimizations.
>
That option on the Sun compilers never did anything.
As pointed out previously there is no such thing as "operating system specific optimizations." That is not possible.
Normally a java compiler produces java byte codes in a class file. There are only two optimization strategies with that. The byte codes and the class file structure. It must produce a class file in exactly the way defined in the JVM spec. Otherwise it is not a java compiler.
So, the only thing a java compiler might do would be to produce byte codes optimized for a specific jvm. I do not know of any that claim to do that.
A simple test of this would be to run the Sun compiler on a windows box and a Solaris box and compare the results.
You might also get a java compiler that produces machine code (executables) rather than byte codes. There are a number of companies that sell those. By definition those are "optimized" for the platform because they produce machine code. The actual speed up however will probably depend on your application and the compiler used.
> So, the only thing a java compiler might do would be
> to produce byte codes optimized for a specific jvm. I
> do not know of any that claim to do that.
To me this is the only open point in this thread: Take for
example the important unix platforms like sun, HP, linux
or others:
Does anybody know about inofficial or official byte code
optimizations for their specific JVM's? One could even think of
JVM bugs that only occur if you do not use the java compiler
"associated" to the JVM ...
You should not perform compile time byte code optimizations for specific runtime environments, they would be exploiting known characteristics of a specific virtual machine which goes some way to rendering your class files non-portable.
Optimisations performed on the byte codes at compile time are -not- platform neutral they are optimisations performed on the Java platform byte codes, remember that Java is not simply a language it is actually the entire platform (development, deployment, runtime etc).
The -O compiler switch used to perform some optimisations to byte codes, it also removes debug information.
Under JDK1.3, -O still performs some optimisations like function inlining, loop roll outs and so on.
Using Sun ONE Net (Formerly Forte) you are still offered the -O option to optimise code even when using JDK1.4.1.
The bulk of optimisations are now performed at runtime transparently by the Hotspot VM. These runtime optimisations can be tailored to the specific native environment the VM is running on as well as applying generic improvements like multiple guard bypass and so on.
> Does anybody know about inofficial or official byte
> code optimizations for their specific JVM's? One could
> even think of JVM bugs that only occur if you do not use the java
> compiler "associated" to the JVM ...
This would not make sense at all. Bytecodes are platform independent and there would be no value in treating them otherwise. If a JVM was somehow broken and its associated compiler was trying work around these defects, then you need a different JVM. This scenario does not exist in the real world.
Chuck
andyba said
>
> The -O compiler switch used to perform some
> optimisations to byte codes, it also removes debug
> information.
>
> Under JDK1.3, -O still performs some optimisations
> like function inlining, loop roll outs and so on.
>
> Using Sun ONE Net (Formerly Forte) you are still
> offered the -O option to optimise code even when using
> JDK1.4.1.
>
Based on what you said above, regardless of the code used, using the -O flag should create a class files with different sizes, because of the missing debug information.
Have you tried this?
Presumably you know what loop unrolling is. So it should be easy for you to produce a small minimal routine that would be easy to roll out using -O. And comparing the byte codes between the two should easily demonstrate the difference.
So could you please be so kind as to present us with an example of the different bytes codes when compiled with and without?
If the loop unrolling seems to complicated then find some other optimization that would seem obvious, and present that.
Until you or someone else actually demonstrates this, I am going to stick to the opinion/belief that the option does not now and never has done anything.
> Does anybody know about inofficial or official byte
> code optimizations for their specific JVM's? One
> could even think of JVM bugs that only occur if
> you do not use the java compiler "associated" to the
> JVM ...
As far as I know, no one touches the javac distributed by Sun, so no, javac itself, for Sun-derived JDKs, behaves exactly the same for all vendors.
This is not to say that optimizations can't be done. Optimizations in general (inlining, loop unrolling, code hoisting, strength reduction, common subexpression elimination, etc.) are all motherhood and apple pie. Good for everyone.
In fact, some Java compilers (jikes is one that comes to mind) do some or all of these (as far as is possible with a language like Java).
But platform-specific byte-code optimizations (i.e. optimizations that are only performed for one platform) are meaningless, because (again) of the very nature of Java.
If you are intending to tie your program to one platform only (or produce different distributions for different platforms), then a compiled Java solution may be your cup of tea. There are a few attempts in progress, including the GNU gcj (the gcc-based Java compiler). However, gcj works only with the Kaffe VM and library, and thus is only at the (roughly) 1.1 level.
>
> In fact, some Java compilers (jikes is one that comes
> to mind) do some or all of these (as far as is
> possible with a language like Java).
Hmmm....I have jikes (Version 1.16 - 10 July 2002) and the command line help lists the following option.
-Ooptimize bytecode (presently does nothing)
> Hmmm....I have jikes (Version 1.16 - 10 July 2002) and> the command line help lists the following option.> > > -Ooptimize bytecode (presently does nothing)> There you go again trying to confuse people with the facts.
