|
Please see below...In this particular case I was, because the program was stuck in a Java method. This naturally does not help me if the program abrubtly ended.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thorbjørn Ravn Andersen
Sent: Sunday, December 09, 2007 4:33 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Training in Green Screen Java performance and debugging?
Sure. This particular problem was a Java 1.3 program doing ftp-transfers which repeatedly got stuck in TIMW. Since this was ancient production code from before my time we could not just throw new versions in there, and I could not attach a debugger (no network access but telnet and ftp) so I could not ask WHERE this happened. Usually I have a stack trace to deal with but I could not figure out how to get one. Well, option 11 on the job gave me a call stack window, and THANKFULLY the stack entries for the java code is very readable so it was very easy to identify the culprit (an accept() waiting for a connection which never came). I believe this is Java 1.3 under V5R1.
Here I would have loved to be able to get a readable Javastacktrace or just the option 11 to a spool file (perhaps even in IFS? *oh*) so I could get an overview much faster than poking around in the call stack stuff.
I'm glad you are able to peek into the details of the job. Keep in mind that when the job finishes (or dies), the job logs have a lot of useful information. If you write down the user id of the job, then you can always use WRKUSRJOB to the job logs. If you have the whole information (job name, user, and job number) you can also use DSPJOB. IMPORTANT! The job information is gone if no spool files were generated. So if you are unable to display a job, it may be because the job finished successfully AND printed output was generated.
Another way where you can see the output of your program is running your java within the qshell (have you tried that?) If you have worked with any Unix shell, you'll feel at home with qshell. Just type QSH in the greenscreen command line. In some ways qshell is a bit limited, but it behaves almost like a unix shell.Yes. I usually use qsh to get the various -X flags right and write shell scripts (where you need to be aware that running these in batch may fill up the job slots, whee), but at the end of the day we want the JAVA/RUNJVA commands to be the ones invoking our Java programs to be able to communicate efficiently with our legacy scheduler.
We also have another system which runs my code noticeably slower than on our development system, and where we have ruled out insufficient memory pool or batch/interactive but not gotten much further yet. From Unix I am used to top and sar which can tell me the paging activity (swap) for a given process and WHY and WHERE it waits. I would like similar knowledge for AS/400 - WHY is the system not giving my process top prority and resources? WHERE does all the resources go? etc. If I recall correctly this is Java 1.4 on a V5R4.Please note that our development machine is an AS/400 running V5R3 - we naturally test the java code inhouse before it is put on the customers machines - and our development machine is MUCH MUCH faster than this particular clients. (and my PC is about 3 times or more faster than our AS/400).
ISeries is notorious for running Java code slower than in PC or Unix machines. I believe that one of the main reasons is the way the iSeries allocates processing time to a process. Windows and Unix will use as much processing power as possible when running a program. So it may be possible that your processor utilization in Unix/Windows goes up to 100% when you run a Java program. That means that if you are the only user on the machine, a program with no I/O may run in 10 seconds. If there were 10 users running the same program at the same time, they would finish in a 100 seconds, that is *10 times* more time to complete. On the other hand, the iSeries philosophy is to provide a more uniform experience... if you are the only user on an iSeries, and then you run the same java program, it may assign only 15% of the processor to the java program at the beginning, so it would take 60 seconds to run; however, if there were 10 users running the same program at the same time that would take maybe a 100 seconds, that is *1.7 times* more time to complete. The user experience is more uniform. However, when a program runs for a long time, the policy of the operating system is to give it a bigger and bigger processor slice, so it can finish it as soon as possible.
Have you optimized your java programs? If not, use command Create Java Program (CRTJVAPGM) and optimize your jar and class files. Although the main (and original purpose) of CRTJVAPGM was to be the equivalent of javac, it can also be used to optimize already compiled code. This is the best way to improve performance. Try to optimize all your jar and class files up to level 40. Just be aware that it may take a long time, but it's worth it.I have actually experimented quite a lot with this as we should do some image conversions from TIFF to something immediately browsable. For something CPU heavy "jitc" was 30% faster than -opt40 ... AFTER being optimized but including JIT'ing. The JIT process took almost a minute before any output was produced, but it STILL overtook the statically compiled code. This is most likely due to very aggressive inlining of method calls. The jit in the 32-bit JVM in V5R4 resulted in the same speed as the classic JIT.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
