RE: Java and CPU -- JAVA400-L

Wow!  thanks for this lengthy explanation!  I'm going to read it 4 or 5 more
times so it will sink in.  :)

Brad

> -----Original Message-----
> From: Larry Loen [mailto:lwloen@us.ibm.com]
> Sent: Friday, March 02, 2001 10:45 AM
> To: JAVA400-L@midrange.com
> Subject: RE: Java and CPU
> 
> 
> 
> Brad Stone asked:
> 
> >What type of compiler is javac considered?
> >What does JIT or direct
> >execution comipilation do to the
> >portability of classes?
> 
> This is one of the great secrets of Java (as revealed at my
> COMMON sessions).
> 
> If you were designing an interpreter and looked at
> the Java byte codes, you'd say "ah, I know what to do with this;
> I can write a decent interpreter."
> 
> But, more critically, if you were a compiler writer, and looked at
> Java bytecodes, you'd say "ah, I know what to do with that, that's
> the intermediate language of a compiler.  I just have to 
> write the code
> generation for my platform and I'm done."
> 
> Any compiler written since the '70s has followed a strategy of
> roughly three phases (nowadays sometimes only two):
> 
> 1.  "Lexically" parse the source into language elements.  For more
> modern languages, this sometimes merges into the second step.
> 2.  Formally parse the source, sending off well-recognized bits to
> something called semantic routines.  These routines produce an
> "intermediate language" that describes the code one would
> generate (but in a model-independent fashion) and a symbol
> table that defines the storage used by the program.
> 3.  A code generation phase that takes the symbol table and
> the intermediate language and generates object code for the
> actual machine in question.
> 
> Javac is really kind of a "half compiler" that does only 
> steps 1 and 2.
> Very
> little optimization of the byte code stream is done and you do get the
> symbol table as well.  This is entirely normal for the first 
> two phases of
> a compiler.  That's why the bytecodes are comparatively
> readible (especially if you do javap).  The Java Virtual Machine
> (JVM) is responsible for taking the bytecodes and executing them.
> 
> This can be done with interpretation (and still is for very 
> small embedded
> devices) or it can be done by generating code.  Because the bytecodes
> are so carefully designed and because of a few key limits (such as
> not allowing C-style casts of integers to character strings), 
> the bytecodes
> can execute with no portability problems whatever as long as the
> target machine does 2s complement arithmetic (big _or_ little endian!)
> and IEEE floating point arithmetic.  All the remaining 
> portability problems
> (outside of JVM bugs) are in places like file I/O, JDBC, etc.  Since
> iSeries
> and AS/400 are 2s complement IEEE floating point machines, portability
> for iSeries is no problem at the raw load-add-store level.    
> The bytecodes
> define the portability, especially for ordinary computation.  
> Sun also has
> a
> massive compliance suite which keeps portability boo-boos to a small
> number.  That's why a JVM with the Sun Java logo means something,
> BTW.  All JVM optimizations have to still pass the compliance suite.
> 
> So, what of optimization?  That is the responsibility of the JVM.  On
> OS/400,
> we have the unique opportunity (thanks Single Level Store) to covertly
> attach a compiled program to the .class or .jar file.  This is what we
> call the "Transformer" or "Direct Execution."  Doing this in 
> a compliant
> manner is one of the great triumphs of any coding team in the last 10
> years.
> Literally no one else has managed this feat.  What it means 
> is that we can
> almost completely apply the normal compiler optimizations to the byte
> stream, just as a conventional "back end" of any commercial compiler.
> And, except for a few compliance issues, this is exactly what we do.
> 
> We also offer (and everyone else does) a Just In Time 
> compiler, starting
> in V4R5.  Here, one does not create a permanent program.  The
> programs corresponding to your class files live and die with the JVM.
> 
> But, the back end compiler processing happens
> just the same.  The Hot Spot strategy that Sun has
> made more famous (and which all JIT IBM JVMs do superlatively
> without the great marketing label) is a two step process.  
> There may be
> just a very little bit of interpretation at JVM startup time, 
> though in a
> server
> environment, even that's probably not worth it.  It is often very
> effective to do an immediate, basic codegen as a Java class file is
> loaded.  About like an OPTIMIZE(20) level for a typical ILE 
> language on
> OS/400.  However, with the Hot Spot idea, and given that the 
> code isn't
> permanent, you can instrument the code a bit, detect which 
> methods run a
> lot,
> and then subject those methods to a second, more expensive 
> optimization.
> This ends up between OPTIMIZE(30) and OPTIMIZE(40) in quality in
> most cases.  The result is now typically less than double the run time
> performance
> of typical C and C++ programs .  I can't readily compare for RPG, but
> it should be about the same as far as "your own code" is concerned.
> 
> I can find examples, in fact, where Java outperforms C code.  The gap
> has narrowed and I expect it to continue to narrow.  In a 
> server world,
> assuming your WebSphere environment (ie, your JVM) lasts a long time,
> then even with a JIT, in the long run, given enough time and 
> investment,
> the Java codegen should be on a par with C++ for sure and probably C
> in most real world cases.  (JIT can sometimes have advantages over
> static compilation, in fact).  Garbage collection in Java is one place
> that will cause a lag of the best C and RPG code, though that is often
> between 5 and 20 percent, and more often 5 nowadays.  And, it might
> even buy back that difference with increased application uptime
> due to fewer bugs, as we always forget to measure downtime when
> comparing performance.
> 
> Now, it is easy to forget, especially in commercial computing, that
> "your own code" (ie the application code) is frequently as low as
> five percent of the total path length.  This is easily 
> forgotten, because
> you can change your source and halve the machine's execution
> cost.  But, you often did that by making your use of OS/400 
> more efficient.
> In Java, "your own code" is more likely to be a larger fraction of the
> total
> execution, because Java has all that portable middleware that 
> displaces
> operating system code and because it attracts problems where
> the application just plain does more computing.  But, even there "your
> own code," proper, need not be a great fraction of the run time.  This
> is especially true if you do significant DB access, which almost
> everyone reading these words typically does.
> 
> 
> 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
> +---
> 
+---
| 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
+---