Agreed - there are high fixed costs to running a JVM. With a large codebase, there are also high warm-up costs for JITing the code up to full speed. Think of this as compiling your code every time you run it :-)
But - there are many types of applications where these costs don't matter at all. Over 10 years ago we helped a customer replace some large systems written in Cobol and Assembler with Java. The main drivers for the system were long running tasks, so the fixed costs didn't matter. In the end, the new system performed much better and more reliably since it was easier to architect them better using Java. As everyone knows, using Java is no silver bullet. Many times Java just allows bad programmers to make an even bigger mess of things. Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Mar 31, 2016 at 9:01 PM, David Crayford <[email protected]> wrote: > On 1/04/2016 8:13 AM, Andrew Rowley wrote: > >> >> I do know that the effects of allocation patterns are very different for >> GC languages and languages like C/C++. In C++ allocating and freeing short >> lived objects is expensive because the memory needs to be tracked. In GC >> languages short lived objects are cheap, it is objects that survive to GC >> that are expensive. This can make it a bit difficult to directly compare >> performance because there might be different design decisions. >> >> > In C++ small object allocation can be done with pool allocators > http://www.boost.org/doc/libs/1_60_0/libs/pool/doc/html/index.html. > > Most of my CPU time seems to be I/O related (processing SMF data). Even >> removing all the reporting seems to make very little difference to the CPU >> consumed. I'm trying to work out if I can reduce the I/O overhead. >> >> > I guess you're using JZOS RecordReader? From what I know of the > implementation it's micro-optimized and it's as good as it gets for Java. > > I don't know about JIT overhead - I think it is probably insignificant >> because it should only compile the methods you actually invoke. >> >> The FTS1 CPU is running CICS, IMS and that one Java batch job spikes past >>> it. >>> >> >> Without other work for competition anything CPU bound will max out the >> CPU, so that's not necessarily a negative - it just means that it isn't >> waiting for other things. E.g. at one site the DBAs greatly increased >> Adabas buffer space. CPU contention increased massively as virtually >> nothing was waiting for I/O anymore. Caused a few problems, but it's a good >> problem to have. It just means that if it can only get 5% CPU instead of >> 50% it will run ~10 times as long. Total CPU time is a better measure than >> CPU%. >> > > Agreed. I probably didn't articulate my point very well. You can't compare > a COBOL batch job to a Java batch job. The COBOL program will use 200K of > memory and use very little CPU where the Java program will be a > multi-threaded monster and gobble up as much memory as it can devour. > That's the nature of the beast. It probably means the density of Java > workloads that can run on a zIIP is far less than conventional programs on > CPs. > > My Java program creates Redis pipeline buffers so uses quite a bit of > memory. When I profile the program in APA I see the following. > > Name Description Percent of CPU Time * 10.00% +3.9% > > *....1....2....3....4....5....6....7....8....9....* > APPLCN Application Code 96.35 > ************************************************ > >> *PATHNAM Application Program 96.35 >> ************************************************ >> > > Parallel CSECT in *PATHNAM 34.86 ***************** > > MarkingS CSECT in *PATHNAM 27.41 ************** > > CompactS CSECT in *PATHNAM 17.11 ********* > > ObjectHe CSECT in *PATHNAM 6.49 *** > > Concurre CSECT in *PATHNAM 3.80 ** > > HeapMapI CSECT in *PATHNAM 1.90 * > > J9ZERZ10 CSECT in *PATHNAM 1.26 * > > Scavenge CSECT in *PATHNAM 0.95 > > CardTabl CSECT in *PATHNAM 0.63 > > Half of the CPU time is spent in GC. Ironically most of this program is > spent running C++ GC code in the VM! ParallelScavenger, ConcurrentScavenger > and MarkingScheme which I assume is part of the mark-and-sweep GC engine. > > What I really want for Christmas is to run C++ programs on a zIIP. But IBM > won't let me :) > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
