RE: Preferred method to access databases from Servlets

Larry,

  I thank you for your through reply, and I stand
corrected. The way you put it it does seem that JITed
code is a resonable fascimile for compiled code
especialy if the compiled code has the overhead you
say it does. I do have one question though (this may
be off topic), if the the class file is a simple to
compile directly to native code as you say why are
there so very few actuall java to native code
compilers out there. I am aware of only a few that are
still an active project. Ibm has the hpj, symantec has
its compiler, tower produces one as well. You would
think that there would be more. I could be that the
JIT makes this unneeded, but there would be some
benefit in makeing full blown compiled code and
incuring the compile time only once.

Thanks for your information  


--- lwloen@us.ibm.com wrote:
> 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, 
=== message truncated ===


=====
Eric Merritt
Information Systems Consultant
McCormack & Associates, Inc.
Rock Hill, South Carolina
(V) 803-327-3358 X 225
eric@mccinc.com
http://www.mccinc.com/

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
+---
| 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
+---