OS400 JVM performance

Hi Everyone,

While working on my recent problem with Excel cell formatting, I had this
discussion with Andy Oliver, one of the POI/HSSF developers.  I'm not a Java
programmer, but I've been hearing a lot on this list about how OS400's JVM
is the fastest, so I thought this might be of interest to those holding that
opinion.  Now that I'm starting to use Java from RPGLE, performance may
eventually be a factor, so I'm interested too. Btw, for those like me who
aren't all that conversant in Java issues, my assumption is that "GC" in the
following means Garbage Collection.

Andy: And I'm betting you're on an IBM VM on a AIX, zOS, OS/400 or OS/390
box. Those have the slowest saddest VM GC implmentations this side of the
Sun so you should conserve that memory.  (The IBM Linux VM's GC ain' great
for high scale either, the benchmarks simply lie).

Me: Interesting.  I haven't seen the benchmarks, but I've been hearing from
others that the OS400 JVM is the fastest because they put part of it in
microcode.  Mind if I toss your comment out to the midrange.com bunch and
see what they say?

Andy: You can if you want but dialect won't change my mind about this.
Increased results would.  :-)

Microcode is irrelevant.  The code generated is only one relatively minor
factor of performance. Runtime complation is a rather difficult thing. A
processor that ran the java bytecode directly might perceivably run faster
at startup than a highly optimized JIT VM on a machine that didn't. However,
after some time, this factors its way out.  meaning the JIT will eventually
get it to where all code that can be compiled to run faster is native code.
Now there is no real machine code advantage....cook time.  Now that might
make a difference for command line tools where startup time is important,
but faster bus speeds and ram speeds probably matter about the same.  Fun to
think about, fun to play with (check out apache harmony project), but mainly
an intellectual excercise.

IO support (channels and streams and sockets) can make a big difference on
platfoms that don't do this as well.  This is especially important so far as
VM support for NIO.  Not so relevent to HSSF right now really, but will
matter in the future probably.

Thread support is CRITICAL for multithreaded apps (like servlet containers).
Linux with the 2.4 kernel was dog slow.  Windows smoked it for
multithreading.  Solaris got smoked until Solaris 9 and the alternate thread
library.  Now Linux with 2.6 and the 1.5 VM is quite good but without doing
any formal benchmarks I'd guess Solaris 9 and it are on par and they smoke
Windows.

However, for POI, the GC performance and memory access is king.  We create a
lot of memory, it has to be cleaned up...the more effective your GC
algorythms and memory management are, the faster POI will run.  IBM's VM GC
startegy is pretty crappy.  Sun's multi-generational parrallel GC in JDK 1.5
is very very good.  BEA's JRockit was king of 1.4.2 GC though it was similar
to IBMs kinda, they did a much better job (and their code generation was
probably second to none since its more or less the
intel guys writing the low level stuff).  Now IBM does their own very nice
impressive benchmarks that prove their VM is the fastest which frankly
aren't worth the paper their not printed on ;-) .  What is important is how
these VMs work on real apps (and in vendor benchmarking they do dirty tricks
like comparing different version with their GC turned completely off).

I've been thoroughly unimpressed with their 1.4.x VMs compared to others on
systems of scale.  I do hope their NIO/channel  performance is better so
that our new optimizations will be fast.

Peter Dow
Dow Software Services, Inc.
www.dowsoftware.com
909 793-9050 voice
909 793-4480 fax

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 7/19/2005