RE: Preferred method to access databases from Servlets -- JAVA400-L

Eric wrote:

>Richard,

> How can you say that java is not interpreted? Ok I
>will grant you that the CRTJVAPGM does produce system
>binaries on the AS/400 but that command does not exist
>on any other platform that I am aware of. As for the
>JIT yes it does increase speed greatly, but it does
>its compile at runtime therefore incurring that
>overhead as it goes, this is not an indication of a
>non interpreted language its just a different way to
>interpret it.

This is an interesting point of view.  I would argue
that in many cases, the _number_ of times something is
compiled has nothing to say, in itself, about how fast it
performs _after_ the compilation ceases.  I would certainly
not argue that simply because I compiled many times instead
of one time, that I was in an interpreted process.  I
do think your argument can still be made (see farther down),
but it is important to really understand what's happening
here.

The Just In Time process is real compilation process.
Native code is produced; it just isn't stored in a file.
The class file format is extremely clever as a basic
technology.

The wonder of it is is that Java's class file is suitable for
both interpretation _and_ compilation.  Speaking as someone
with some experience with interpreters and compilers both,
I can tell you that the class file format is an extremely
clever squaring of a circle.  That is to say, if I was
writing a Java interpreter, I'd look at the class format
and know what to do.

But, if I was asked to write the back end of a Java
compiler (one that did a conventional compile), and
someone gave me the class file format as the input to
that back end process, I would _also_ know
what to do.  The AS/400 Transformer, in fact, works
_from_ the class file to do its compile and what it does
is different in detail but not much different in concept
than what a conventional *PGM create phase
does to the output of the ILE C compiler.  There is a
fair amount of code that serves both, in fact.

In other words, Java's class file is very suitable
in structure to produce actual, compiled code.
And, the JITs does so.

> Java is still interpreted or close to it, and will be
>until some one comes up with a good  cross - platform
>compiler that will turn it into native code.

As far as I can tell, you are mistaken
here.  The Just In Time process produces
actual, native code.  The question of the
cost of producing it is a real problem, and if you
mean that by what you say here, you have a point.
But, if the Java Virtual Machine instance runs long enough,
as it might in a server situation, the cost of the added
compilation due to the JIT process becomes a nonfactor
in practice.  It then becomes a question of the
quality of the JIT-ing process.

>Even this
>option is probably not a good thing as we will loss
>the ability to pick up a class file and run it
>anywhere.

But, this cross platform .EXE assumption turns out to be
an unnecessary restriction.  There is nothing particularly magical
about having a stored binary program sitting on a hard file,
especially with modern CPUs.  The question at hand is getting
native program code into memory.  This, the Java JIT process
does quite effectively.

I've read claims from the Intel Java crowd that suggest that at least a
simple compiled process (a first level JIT) can be produced for about
the same CPU cost as the loading and relocation costs of a (much larger)
.EXE or .DLL program.  That's probably not quite true, but making a program
ready for execution on a modern computer (with things like cache flushes
and kernel calls to tell it "set protection bits to let this
this memory region run code now") is surprisingly
expensive.  It helps mask the cost of the JIT process over and above the
simple byte movement of a large, precompiled program where the
cache flushes et. al. also take place.

In any case, the simple JIT cost is a one-time cost and occurs farily early
on in the JVMs I have knowledge of (other than the '400's, which works
a bit differently as it doesn't have to worry about applet performance).

If your Java program does not run very long, this JIT-ing cost
is an important factor.  But, if your Java program runs
for many minutes or hours (as it might in server contexts), the cost
of the JIT is basically a non-factor after the first half hour or
so, if not much sooner on a modern machine.  The problem would
be that the simple one-pass JIT would not produce highly optimized code
(hence, the advantage of the AS/400 Transformer technology).

Moreover, to give the devil its due, Hot Spot is based
on a kind of casino-betting strategy that
says it can detect the most frequently used classes and subject them
to a more thorough and traditional compile process.  The traditional
compiler optimizations are all available.  Presuming it actually
guesses correctly, the compile cost is a "two time cost" and, of course,
the second compile is longer than the original simple JIT pass compile,
with some small amount of code runing at the lower optimization (simple
JIT) level.  This does, therefore, take some time, but time that begins
to be repaid almost at once.

Overall, if the Java Virtual Machine has a long enough life, no one notices
the added time and there's no reason to suspect the ultimate code is
substantially slower than an ordinary compiler produces, because they're
doing the same kinds of things.  To be sure, it may be that the Hot Spot
guesses wrong, but then all you get is slow compiled code, which
will still beat a true interpreter.  What remains as any deficit comes more
from things like Java Garbage Collection, added overhead from Virtual
Function
calls and like things that Java put in explicitly to make programming
easier and which would remain as costs even if one used a traditional
compile process to produce Java code.

Of course, Hot Spot is partly just a name; IBM's JIT
technology has quietly done similar things since 1.1.8 and even
1.1.7.

Thus, the AS/400 JIT does many of these things as well.
In our current Performance Capabilities Guide for V4R5, we rate
the AS/400 JIT at about Transformer OPTIMIZE(30) in quality.  This
is not absolutely stellar, but it would run circles around any real
interpreter and would be akin in performance to many real
world compiled products that don't ship at maximum optimization
for (e.g.) field debuggability.

Perhaps one could stretch a point and call all of this JIT style
technology "interpretation" while the various JIT stages are
running.  This makes your argument, after a fashion, because
you are correct that there is added overhead for the JIT-ing process
while it runs, and so (like interpretation) is slower than straight
out compiled code, though not by as much as you might
think, for at least the simple JIT.

But, after a while, all the JIT-ing that is going to take
place has already  taken place.  After that, the hardware really
sees about what it always sees -- compiled code of varying quality
in the JIT case and compiled code of fully optimized form
on the AS/400 Transformer technology case.  This is not
at all like an interpreted case, either in structure or performance.

So, the OPTIMIZE(40) Transformer should have an advantage over
the JIT for (among other reasons) that it does not have to out-guess
which classes are used the most and because it really is a one-time
cost.  But, I would not agree that the result of all this
JIT-ing is on the same scale as a classical interpreter's cost.
It is much faster than any interpreter I know of for all but the
shortest-lived Java invocations.


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
+---