Re: What CRTJVAPGM does

[blairw@xxxxxxxxxx]

Larry Loen wrote:

> Starting in V4R5, we also added the more ordinary "just in time"
> (JIT) compile process, which creates some on-the-fly compiled
> code, but CRTJVAPGM OPTIMIZE(40) produces better
> code than the "JIT" process does.  JIT and CRTJVAPGM objects
> can interoperate as well.

Considering the superior code-gen of CRTJVAPGM, one might ask, "Why do a
JIT at all?"  The answer is subtle, but its impacts are pervasive in
server-side Java.

One key motivation for implementing a JIT on the AS/400 is the widespread
use of so-called "user classloaders" in application servers.  User
classloaders are a Java construct that provide a way for Java to a)
effectively change the CLASSPATH of an application in an already-running
JVM, and b) provide for the garbage collection of *classes* (instead of
just objects).  Together, these capabilities reduce or eliminate memory
"leakage" (heap creep) in a long-running JVM (such as in an application
server), and provide dynamic "grouping" within a single shared JVM.  Very
powerful combo.

However, from the CRTJVAPGM perspective, there is a dark side to user
classloaders -- their implementation never ever gives an actual *file* to
the JVM, just an *array of bytes* containing the raw classfile data (e.g.
constant pool, bytecodes, etc).  So, before we had a JIT, we initially
opted to default to interpreted mode for classes loaded by a user
classloader.

Well, our friendly performance folks hit us on the noggin with their
numeric hammers, so we next opted to do a low-optimization CRTJVAPGM by
default, discarding the JVAPGM when the JVM went down.  (We had no actual
file in the IFS to "hang" it on, after all.)  Finally, since one size
rarely fits all, we provided a property the user could specify to tell the
JVM what optimization level to use for these classes.  Even that provision
had the downside of being global to the entire JVM.  <sigh>

Clearly, one reason that CRTJVAPGM is so wonderful is because it allows you
to amortize the *significant* computational expense of sophisticated code
analysis and optimization over possibly very many executions of the class.
(This is the same as for any traditional language environment -- if the
code runs twice as fast when optimized, and it runs several thousand times,
it's acceptable that it took four times as long to compile.)  However,
since the JVAPGM can't be preserved from JVM to JVM in the case of a user
classloader, this key wonderfulness is *lost.*

What's a mother to do?

That's where the JIT comes in, because it is perfectly suited to this sort
of "dynamic" environment -- the environment of the user classloader and the
application server.  And, frankly, the performance of the JIT code is very
good, largely because all of its optimizations have complete knowledge of
the runtime environment.  CRTJVAPGM optimizations always have to be very
careful about the possibility of a CLASSPATH change or other change
rendering the optimization invalid.  These optimizations can be called
"guarded," since there is always an escape clause at runtime that reverts
to interpreted mode if the assumptions made at compile time are no longer
valid.  (In practice, this is rare, but is technically required by the JVM
specification.)  The JIT, on the other hand, knows exactly what's what, and
can do its optimizations with certainty and impunity, knowing that the
entire JIT code store will vanish into the ether with the JVM it's running
under.

Anyway, I hope that adds a little context to the discussion of CRTJVAPGM...
Back to my regularly-scheduled programming.

-blair

Blair Wyman -- IBM Rochester -- (507) 253-2891
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The first principle is that you must not fool yourself -
  and you are the easiest person to fool."   -- Richard P. Feynman

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