From: Walden H. Leverich
I know of many installations running JVMs on the System i, but they're
all in the context of a batch process app server (tomcat, websphere,
etc.) For those that are calling java programs from interactive jobs,
what's the performance like? Both from a first call (start JVM) and a
subsequent (active JVM) point of view? Is it something you'd want to do?
No, I wouldn't want to do it. First, starting the JVM takes a significant
amount of time. And even though subsequent calls are much faster, that
performance stills depends on how many JVMs are running, and in today's
i5/OS implementation, a JVM cannot be shared between two jobs. Every job
that runs Java must have its own private JVM.
The JVM per job issue is one I've struggled with since the JVM was
implemented on the platform. I've discussed the concept of a shared JVM
with Blair Wyman (pretty much the guru of System i Java) and he has made it
clear that the technical problems are such that it isn't likely to ever be
done. Mind you, no matter how hard he tried he was unable to dumb down
those technical problems to my level of understanding, but he was pretty
adamant that trying to share a single JVM between multiple jobs within i5/OS
work management was way more trouble than it was worth. Of course, I
remember that being said about multi-threaded RPG, too <grin>.
The next relevant point is that the JVM is very susceptible to traditional
i5/OS memory management. The swapping mechanism of i5/OS is such that
sharing memory between traditional i5/OS work and the JVM causes great
problems; that's why I recommend that people always run the JVM in a
subsystem with dedicated memory removed from the rest of their normal jobs
(both batch and interactive).
Those two points being made, it's pretty clear to me that using the JVM in
an interactive environment except for the most one-off types of work is
probably not a good thing. I mean, using it to do a utility function is one
thing (my CPYSPLFPDF tool does it), calling Java for every record in an
order is probably not as good an idea. Having 100 jobs calling Java for
every record in an order is chaos.
So, if performance is not a big issue and it's a function you perform
occasionally, invoking a JVM in an interactive job is okay. The JVM will
execute and then quiesce much like any other program (albeit using a lot
more memory). The next time you use it, the JVM will need to be swapped in
and that will consume resources. The more you do it, the more you will
bang.
If performance is the issue, then, I recommend the batch approach. Use a
data queue or a database file to communicate requests to the JVM and wait
for responses. Even processing synchronously, you will get better
performance than having multiple interactive JVMs. And if your application
allows for submitting asynchronous requests, so much the better for your
interactive jobs.
Joe
midrange.com
