RE: Java and CPU -- JAVA400-L


Brad Stone asked:

>What type of compiler is javac considered?
>What does JIT or direct
>execution comipilation do to the
>portability of classes?

This is one of the great secrets of Java (as revealed at my
COMMON sessions).

If you were designing an interpreter and looked at
the Java byte codes, you'd say "ah, I know what to do with this;
I can write a decent interpreter."

But, more critically, if you were a compiler writer, and looked at
Java bytecodes, you'd say "ah, I know what to do with that, that's
the intermediate language of a compiler.  I just have to write the code
generation for my platform and I'm done."

Any compiler written since the '70s has followed a strategy of
roughly three phases (nowadays sometimes only two):

1.  "Lexically" parse the source into language elements.  For more
modern languages, this sometimes merges into the second step.
2.  Formally parse the source, sending off well-recognized bits to
something called semantic routines.  These routines produce an
"intermediate language" that describes the code one would
generate (but in a model-independent fashion) and a symbol
table that defines the storage used by the program.
3.  A code generation phase that takes the symbol table and
the intermediate language and generates object code for the
actual machine in question.

Javac is really kind of a "half compiler" that does only steps 1 and 2.
Very
little optimization of the byte code stream is done and you do get the
symbol table as well.  This is entirely normal for the first two phases of
a compiler.  That's why the bytecodes are comparatively
readible (especially if you do javap).  The Java Virtual Machine
(JVM) is responsible for taking the bytecodes and executing them.

This can be done with interpretation (and still is for very small embedded
devices) or it can be done by generating code.  Because the bytecodes
are so carefully designed and because of a few key limits (such as
not allowing C-style casts of integers to character strings), the bytecodes
can execute with no portability problems whatever as long as the
target machine does 2s complement arithmetic (big _or_ little endian!)
and IEEE floating point arithmetic.  All the remaining portability problems
(outside of JVM bugs) are in places like file I/O, JDBC, etc.  Since
iSeries
and AS/400 are 2s complement IEEE floating point machines, portability
for iSeries is no problem at the raw load-add-store level.    The bytecodes
define the portability, especially for ordinary computation.  Sun also has
a
massive compliance suite which keeps portability boo-boos to a small
number.  That's why a JVM with the Sun Java logo means something,
BTW.  All JVM optimizations have to still pass the compliance suite.

So, what of optimization?  That is the responsibility of the JVM.  On
OS/400,
we have the unique opportunity (thanks Single Level Store) to covertly
attach a compiled program to the .class or .jar file.  This is what we
call the "Transformer" or "Direct Execution."  Doing this in a compliant
manner is one of the great triumphs of any coding team in the last 10
years.
Literally no one else has managed this feat.  What it means is that we can
almost completely apply the normal compiler optimizations to the byte
stream, just as a conventional "back end" of any commercial compiler.
And, except for a few compliance issues, this is exactly what we do.

We also offer (and everyone else does) a Just In Time compiler, starting
in V4R5.  Here, one does not create a permanent program.  The
programs corresponding to your class files live and die with the JVM.

But, the back end compiler processing happens
just the same.  The Hot Spot strategy that Sun has
made more famous (and which all JIT IBM JVMs do superlatively
without the great marketing label) is a two step process.  There may be
just a very little bit of interpretation at JVM startup time, though in a
server
environment, even that's probably not worth it.  It is often very
effective to do an immediate, basic codegen as a Java class file is
loaded.  About like an OPTIMIZE(20) level for a typical ILE language on
OS/400.  However, with the Hot Spot idea, and given that the code isn't
permanent, you can instrument the code a bit, detect which methods run a
lot,
and then subject those methods to a second, more expensive optimization.
This ends up between OPTIMIZE(30) and OPTIMIZE(40) in quality in
most cases.  The result is now typically less than double the run time
performance
of typical C and C++ programs .  I can't readily compare for RPG, but
it should be about the same as far as "your own code" is concerned.

I can find examples, in fact, where Java outperforms C code.  The gap
has narrowed and I expect it to continue to narrow.  In a server world,
assuming your WebSphere environment (ie, your JVM) lasts a long time,
then even with a JIT, in the long run, given enough time and investment,
the Java codegen should be on a par with C++ for sure and probably C
in most real world cases.  (JIT can sometimes have advantages over
static compilation, in fact).  Garbage collection in Java is one place
that will cause a lag of the best C and RPG code, though that is often
between 5 and 20 percent, and more often 5 nowadays.  And, it might
even buy back that difference with increased application uptime
due to fewer bugs, as we always forget to measure downtime when
comparing performance.

Now, it is easy to forget, especially in commercial computing, that
"your own code" (ie the application code) is frequently as low as
five percent of the total path length.  This is easily forgotten, because
you can change your source and halve the machine's execution
cost.  But, you often did that by making your use of OS/400 more efficient.
In Java, "your own code" is more likely to be a larger fraction of the
total
execution, because Java has all that portable middleware that displaces
operating system code and because it attracts problems where
the application just plain does more computing.  But, even there "your
own code," proper, need not be a great fraction of the run time.  This
is especially true if you do significant DB access, which almost
everyone reading these words typically does.


Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---