Re: Servlet Load Times under WAS on an iSeries! -- JAVA400-L

>I have some simple servlets that I've deployed on our iSeries under both
WAS
>2.02 and 3.5.2 and in both instances the initial load times are
unacceptable

Long-time listener, once-in-a-while caller...  This rang a bell, so I
thought I'd offer up my two cents' worth:

Key parameters in any analysis of this behavior necessarily include the
OS/400 version/release, the JDK version, and the WAS version.  (I'm by no
means a WAS expert, but know a little about the JVM.)  Offhand, I will
speculate that you are running a bit "back-level," and that the issue with
loading times you're seeing has been addressed.  (Hope springs eternal.  ;
-)

Let me explain:

Servlet classes are a special kind of critter -- they are loaded by a
java.lang.ClassLoader other than the system "default" class loader, and
therefore the "opt40" solution is problematic and potentially ineffective*.
It is also possible that you've made modifications to the JVM startup
properties, based on now-dated advice from IBM, to address this issue in
earlier releases.  (There is also a slight chance these changes could be
affecting your current behavior, even if you've brought your OS400/JDK/WAS
levels up-to-date, though this is unlikely.)  So much depends on your OS400
version, though...

I strongly urge you to ensure you have the latest level of the Java "group
PTF" for your machine.  The exact PTF number depends on OS400
version/release, and the group PTF brings many related fixes onto your
machine in one "chunk."  One sublety of group PTFs is that you need to use
a DSPDTAARA command to determine the "level" of any existing group PTF, and
then if it is outdated you re-request the *same* PTF number.  The new
"level" you receive includes all the fixes from all the foregoing instances
of itself, plus new fixes.  I'm sure the service website has the low-down.
Here's a link I stumbled over in a google search for "java group ptf":

http://www-4.ibm.com/software/webservers/commerce/servers/downloads/as400/v4.1/ptf.html

Anyway, HTH.  Here's some additional background on the opt40 issue.

-blair

* The reason that "opt 40" does not benefit classes loaded by a so-called
"user class loader" is subtle, but important.  The RISC "instruction
stream" for a class -- the instruction stream built by the Java Transformer
-- is encapsulated in a special sort of service program.  Rather than this
"pseudo-object" being contained in a traditional library, however, this
instruction stream is addressed using the file node of the Java class file
in the IFS.  So, when the system default class loader loads a class, it is
handed the name of the IFS file to open, a handle is obtained, and the
associated "Java program" can be found.

When a "user class loader" is involved, all the JVM gets to "see" is an
array of bytes -- there is no IFS file handle (and therefore no associated
Java program) to be found.  This is why opt40 is fruitless in an
environment with user classloaders (such as WAS).

Before we had our wonderful JIT, our only recourse was to build these Java
programs "on the fly," and to discard them when the JVM came down.
Initially, we spent a minimal amount of time doing this throw-away
conversion (creating an interpreted implementation), but then long-lived
classes were running interpreted, and thus unacceptably.  Next, we provided
properties that could govern the opt level of this "throw-away" effort, but
only on a JVM-wide basis, and obviously no single answer *could* work in
all cases.

Ironically, the JIT came along "just in time," itself -- the addition of a
special version of the Tokyo Research Lab JIT to our JVM implementation
saved us from an uncertain future, considering the ubiquity of user class
loaders in application servers such as WAS.

Finally, if user classloaders are so troublesome, why would any piece of
software (such as WAS) use them?  The answer is fundamental to the value
proposition of any application server: the ability to reclaim unused
storage.

When a class is loaded by the system default class loader, an object of
type java.lang.Class is allocated in the JVM.  This object can never be
garbage-collected, even if all of the instances of its corresponding object
are unreachable.

However, when a class is loaded by a "user class loader," it can be known
that all classes that require that class were loaded by the same (or some
child) class loader, and therefore can be discarded when the
java.lang.ClassLoader object can no longer be reached.  This ability to
reclaim the storage for java.lang.Class instances, while seemingly minor,
is crucial to maintain a flat memory utilization profile in a 24x7
configuration.

-blair

Blair Wyman -- iSeries JVM -- (507) 253-2891
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"I was born not knowing, and have had only a
little time to change that here and there."   -- Richard P. Feynman




                    "Sal Stangarone
                    Jr."                     To:     <java400-l@midrange.com>
                    <sals@mrc-Producti       cc:
                    vity.com>                Subject:     Servlet Load Times 
under WAS on an iSeries!
                    Sent by:
                    java400-l-admin@mi
                    drange.com


                    09/12/2001 10:02
                    AM
                    Please respond to
                    java400-l





I have some simple servlets that I've deployed on our iSeries under both
WAS
2.02 and 3.5.2 and in both instances the initial load times are
unacceptable
(15 seconds or more).  Once loaded they perform well (under 2 seconds).  I
know I can have the Servlets loaded as part of the WAS startup but I don't
understand why these servlets take so long to load on our iSeries.  I've
deployed the same servlets to a standalone PC utilizing Tomcat as the
server
and I see minimal (under 5 seconds) startup time needed there even though
its a small PII 233 PC.

I have tried optimizing my class file to opt 40 and while that has some
effect it's minimal.  Has anyone else experienced this?  Is this WAS or my
iSeries any ideas?

Feel free to contact me privately or publicly with any questions.

Servlet on my iSeries http://www.crazybikes.com/servlet/MRCSRVDEMO.I00220s

Servlet on my PC
http://209.125.112.140/employees/servlet/MRCSRVDEMO.I00220s

I appreciate your help.

Sal Stangarone
630.916.0662

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