> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of GAVIN Darren * OPS EAS > Sent: Thursday, September 20, 2007 6:15 PM > To: [email protected] > Subject: Re: JAVA un z/OS > > > Something to Remember, > > Java is a Byte Code (two bytes actually) interpretive language, where > the byte code corresponds to a Machines Instruction on the > Virtual CPU. > > When a compiled Java program runs, it still must interpret > the Byte Code > into the actual CPU's Byte Code, then process the > instruction. The Byte > Code set of Java includes Virtual Machine Instructions that > may not have > a counterpart on various real CPU's, these have to be > translated into a > series of real machine instructions that give the results expect.
The Java JIT compiler and the ability of the JVM to "cache" some classes helps to reduce this overhead. > > Additionally in the case of primitive integers, Java has to > switch them > from Little Endian to Big Endian before sending the CPU instruction, > than back after the instruction is done. I don't know how the JVM is coded, but the current zArchitecture machines have LOAD REVERSED and STORE REVERSED instructions to do this. There are 2, 4, and 8 byte variants of these instructions. > > No matter how much you try and tune Java, or listen to Java Only folks > explain that it's just as fast. It simply is not, at best it is only > marginally faster then running REXX in interpretive mode. > > The same program in COBOL, C, or Assembler will out perform > Java from 10 > times to hundreds of times faster, and use a heck of a lot less CPU > cycles. I agree totally with this. But, then again, I think most things should be coded in optimized HLASM, not COBOL or C. > > This is one of the main reasons to avoid Java, especially if > you are in > a shop that bills out CPU Cycles. Unless you can afford a zAAP processor to offload the Java work. Then, despite Java's performance problems, it might actually be cheaper to run a Java program than a legacy program. A zAAP processor always runs a "full speed". So, for a heavy Java workload, a shop might be able to get along with a smaller MSU processor to reduce software costs while running their Java workload (WAS? JBOSS? Tomcat?) at full speed. The only negative is that IBM requires that you have as many CPs as you do zAAPs. If the shop is DB2, then they might be able to offload some DB2 work to a zIIP, which also runs at "full speed" at all times (I think that's right - if not, somebody will correct me, I'm sure!) > > Darren > -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
