Re: What CRTJVAPGM does

[lwloen@xxxxxxxxxx]

These are really question I should be answering, since I
have a lot to do with the Performance Capabilities Guide and
the Java Performance chapter in particular.

Gary asked:

>1.  Considering only the runtime performance (not compile time), is the
>runtime performance of CRTJVAPGM OPTIMIZE(40) with "guards" that much
>better than the JIT with its runtime knowledge that it is worth it to
>perform the CRTJVAPGM?

As far as I can tell, in what we measure, OPTIMIZE(40) will beat
the JIT.

As I said earlier today, our published claim is that the JIT is at
roughly OPTIMIZE(30) performance today.  This will vary somewhat,
but it's a good guide, if a rough guide.

To give an idea, I generally observe that OPTIMIZE(20) is roughly
twice as slow as OPTIMIZE(40) and OPTIMIZE(30) is somewhere in between,
and often closer to OPTIMIZE(40) than OPTIMIZE(20).  But, these
things vary.  40 is faster than 30 is faster than 20 is pretty reliable.
Exactly where the JIT ends up varies, but it is closer to 40 than 20
and so 30 is a good guide for a general publication.

It may be that someone will produce an application where
the JIT actually wins.  I haven't seen it yet, but that's
no proof it won't happen now and then.  I don't expect this
to be typical, however.

>Do you see the runtime performance of the JIT
>catching up to CRTJVAPGM?

That's a question that probably has no real answer, at least
not one that anyone should be taking to the bank.

Part of this depends on the evolution of Java itself
and how people use it in the future.

Clearly, there are optimizations that the JIT can do that either
OPTIMIZE(40) cannot do or cannot do without added code.  But, the
question then becomes "will those features be used enough to wipe
out the other advantages of OPTIMIZE(40)"?

All I can really say is "OPTIMIZE(40) wins today."  For the rest,
you need a crystal ball.  Generally, I tend to presume that today
is a good guide to tomorrow.  But, that's a heuristic and not
a real prediction.

>2.  From a runtime perspective, at what optimization level, if any, is
>the JIT code faster than CRTJVAPGM?

Again, our published document says that JIT is "about" OPTIMIZATION(30)
which really means sometimes a bit better than that, sometimes a bit
worse.

>3.  Does the JIT do a "mixed mode" analysis to only JIT classes that
>will be executed a lot or does it JIT compile everything?

I'm not sure what the answer is, and it may change over time.
There are different strategies that have been used at different
times.  The '400 version of the JIT will probably be more pro-JIT
than other JVMs because the reasons I know of for delaying JIT don't
really apply in a server world.  Certainly, the 'Hot Spot' notion
of seeing which classes "run lots" and then doing a bit more
aggressive code gen has been around not just in Sun's code, but
in IBM's JIT code since at least 1.1.8 if not 1.1.7.  Thus, the
question probably boils down to not "whether to JIT" but
"how aggressively to optimize" and "when to do the stronger one."
There's no simple answer to that.

>4.  Is the compile time overhead of the JIT large enough to justify
>maintaining both the JIT compiler and the CRTJVAPGM compiler going
>forward?

To my mind, this really isn't the question.  The question is whether
CRTJVAPGM OPTIMIZE(40) continues to outperform the JIT.  As long as
it does, then that gives IBM an incentive to produce both.

In a server context, the JIT cost is likely to be somewhat of a
"start up" cost akin to the cost and frequency of starting up an
OS/400 subsystem (or only slighly oftener).  I'm not sure that
this is a precise analogy (it really relates to how often WebSphere
starts up added JVMs, but I expect it to be on that order of
cost).

This won't be quite as true or as clean for some JSP environments,
if the underlying JSP file itself changes, but I expect it may
well hold true in the servlet and even application environments very
broadly.  That means that in practice, the JIT cost will not be
a big swinger for most uses of Java on the '400, especially
servlets, since it will be (essentially) a Monday morning kind
of cost.

Thus, the question really goes back to how close the JIT gets to OPT(40).
And, as I've indicated, that's really a crystal ball question in the end.



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