Re: Preferred method to access databases from Servlets

Gary Peskin wrote:

[snip]...
> I'm running out of a .jar file
> so I can't rely on CRTJVAPGM running on my first invocation and
> persisting the *JVAPGM like it does with a .class file.

Actually, starting in V4R4, we do persist the *JVAPGMs when you run
in a jar file, but *only* for those classes in the jar file that
are actually accessed.

The advantage to *explicitly* running CRTJVAPGM against a jar file is
that intra-jar optimization opportunities are leveraged -- every
classfile in the jar is unconditionally transformed, so guarded
optimizations can be performed between the classes within the jar
file.

> Is there any
> thought of combining CRTJVAPGM and the JIT so that the JITted code is
> persisted on first use where possible like CRTJVAPGM does now but
> extending this to .jar/.zip files?

The problem with this approach is that as soon as persistence is even
*considered*, then the overhead of satisfying the dynamic requirements
of Java becomes very significant.

Suppose we have a case where the JIT chooses to inline a
small called method.  This is perfectly legal, since the JIT
knows absolutely and without question which method is being called
*this* time (and only this time).

If I want keep that JIT-generated code stream, I have to guarantee
that the next time I run through this inlined method body that it
is exactly the same method, from the same class, with the same
next-level dependencies, etc. as it was when I did the inlining
initially.

Ouch.

If I don't do this, I'm no longer compliant to the dynamic requirements
of Java, and there is heck to pay.

Oops, I said "heck."  There goes my bonus.  *8-)

-blair


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