Dan Kimmel skrev:

I've not yet switched to the technology package because it runs Java 5 (or better) and my application, for various reasons, is still at 1.4.2.

On the other hand, I've had good performance from rather large, long running java applications on i if I give them enough room.
OS400 doesn't seem to be very adept at letting the heap size grow. So I set the max and min (or starting) heap size in the java command to an adequate and equal value. Then, I try to isolate the java application in a storage pool that is double that size. There's still a little lag when classes are first loading, but not nearly so much as when the heap is simultaneously trying to grow. Once loaded, you'll never notice it's java and not native RPG as regards performance.

I think the slowness you see once the application has been left alone for a while is not the fault of garbage collection, but of OS400 rather agressively making space available for other applications. That's the rational behind isolating in a storage pool that OS400 memory management will leave alone as there's no other programs attempting to run in that space.

I've discussed your explanation with my colleague who is the OS/400 expert, and we agree that what you describe makes sense. I've repeatedly said that "my application is being swapped out" which does not make sense to OS/400 people since apparently IBM calls this something else.

Oh, well, we've postponed the J9 migration, and investigate the storage pools based on an recommendation in a WebSphere document for tuning the JVM of needing at least 125% of the maximum heap size. I'll report my findings back. Hopefully this will make the variations in response time smaller. We've seen responses from the web service including a cobol call in less than 80 ms. This would be nice to have as the general case.

Thanks for your response - it's been very helpful.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.