× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thor,

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 also had better performance results with non-native JT400. It seems that native JT400 tries to load the data management routines into the same storage pool as the application whereas non-native will use the prestart jobs (QZDASOINIT) in the storage pools assigned to QUSRWRK. IBM did some great optimization and management on those jobs. Native JT400 routines running in the same storage pool seem to crowd out my java heap or encourage OS400 to make room again.

Dan Kimmel

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thorbjørn Ravn Andersen
Sent: Tuesday, December 15, 2009 8:05 AM
To: Java Programming on and around the iSeries / AS400
Subject: Differences in actual behaviour between Classic JVM and J9 JVM (theTechnology one).

Hi.

I have had quite a bit of fun trying to get a smallish Java program to behave decently under the Classic JVM as it is very slow at first invocation (a lot of classes needing to be initialized) plus after being left alone for a while, plus - I think - if garbage collection hits while processing.

We have now essentially done what we within reason can do, and it is still not satisfactory, so we are now considering switching to the new
J9 one (IBM Technology something). I did some experiments earlier and we found that the java.library.path property had changed form plus we had some issues with the native jt400 forgetting we just sent a CHGLIBL command, which is why we chose to stay on the Classic JVM, especially since our own development system is V5R3 which doesn't have the new stuff (upgrade in the horizon, not applicable right now).

Well, that decision may be reversed now. In order to avoid nasty discoveries up to a deadline I'd really like to hear others experiences of "interesting" differences or tales like "no problems at all even with jt400 foobar voodo". I am already aware that adopted authority is not supported which is ok.

I'd appreciate any help

/Thorbjørn
--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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.