I'm curious, Andrew - Have you looked at the com.ibm.jzos.fields package for field mapping of records? These can be made to use fancy support in the JVM for inline JIT replacement of primitive access with machine instructions.
There is also some tools on the JZOS developerWorks site - the JZOS RecordGenerator. This tool will allow you to read Assembler DSECTS or Cobol copybooks and generate Java classes that use the runtime classes from com.ibm.jzos.fields. See: https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=2acdb076-7582-45b5-93a5-781f90169bd3 Regards, Kirk Wolf Dovetailed Technologies http://dovetail.com PS> The JZOS RecordReader (for eligible data sets) uses a JNI library that uses best-practices BSAM techniques for efficiently reading sequential data sets. The JNI interface is block-level, rather than record-level, which helps a great deal. The only part that you couldn't do yourself is to make the JNI library zAPP/zIIP eligible. The JZOS JNI libraries *are* zAPP eligible, since they are part of the IBM JRE. On Thu, Mar 31, 2016 at 7:13 PM, Andrew Rowley <and...@blackhillsoftware.com > wrote: > On 31/03/2016 23:34, David Crayford wrote: > >> Thanks for the info Andrew. We use the default GC options and our >> workloads are both long running agents and batch jobs. I really do want to >> learn a lot more about how to tune the JVM for each specific workload. The >> SMF 30 records are useless. How do I find out how much time is spent in JIT >> overhead compared to actual processing? What tools do you use to profile >> your JVM apps? >> > > You probably know more about it than I do. I am pretty new to Java on > z/OS, coming from C#. I did some basic GC testing by running the same job > 10 times and taking the average for different GC options. I tried > optthruput because it sounded like what I want for Java batch, but from > memory total CPU increased by 2 or 3 times. All the GC options I tried > changing either increased CPU or made no change, so I have just been using > the defaults. > > There is an option somewhere where you can see the time spent in GC, the > Java guys say that as a ROT if it is >5% try a different GC strategy. There > are so many knobs you can tweak though you could spend an awfully long time > measuring their effects and interactions. > > 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. > > 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 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%. > > > > -- > Andrew Rowley > Black Hill Software > +61 413 302 386 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
