Re: JDBC HIGH CPU and Restart Issue

Den 07/05/10 20.49, Joe Sam Shirah skrev:

Hi Thorbjørn,

I'll own up that I haven't used the J9 JVM's so far, so the rest is just
my understanding. Real world users, please add your experiences. I'll soon
be starting on a client project (that may go commercial subscription -- let
me know if your CFO wants to rein in cash flow and receivables) with what I
would describe as a 4-tier system. The 32 bit jvm makes a lot of sense for
the 4th tier, and I'll be happy to share any AS/400-centric issues as I go.

Looking forward to hear your experiences.

The J9 JVM is much more similar to other JVM's in terms of tuning and
operating characteristics. For technical information, google:

"Holly Cummins" ibm jvm

Dr. Cummins adds a whole new meaning to "blue". BTW, this is pretty
important reading because the classic JVM is due to go away.

Very productive and bright young lady there. 676 hits on Google. Quite a bit of reading to catch up on.

The main thing, IMO, for midrangers (and mainframers) to keep in mind is
that most mainstream JVM and grabage collection discussions pretty much
assume a dedicated machine for server apps. On the AS/400, I'm always very
sensitive to the more common scenarion of many users and jobs going on, and
the need for balanced, consistent operations. That's one of several reasons
I prefer to run JEE and web apps on a separate platform; I can have a
relatively cheap dedicated box and access the AS/400 for what I need.

The IBM i is a very expensive Java platform, and you can get a lot of power having a few x86 satellites circling around it. Especially since if you need to work with native resources, you need to go through a network connection and a prestarted job, both from the x86 and the IBM i itself (or has that improved), and x86 has much more cpu power.

The need for that type of knowledge and understanding won't go away with
J9. I would be less concerned about paging with J9, although in-memory is
always going to be faster. But, in the real world, no paging is often not
going to be a realistic option, and other systems cope reasonably well with
paging. Again, IMO, the big issue in the future is going to be properly
handling and writing parallel code to deal with lower powered multi-core
systems

The problem with paging in the classic JVM is not as such the paging, but the fact that the garbage collector 1) wants to peek at all the memory every time, and 2) if it gets too slow - e.g. when paging - it halts the main program. Apparently the cure here was to throw out the JVM instead of creating a better garbage collector. Oh well.

But enough opinion. What do the real worlders have to say?

Oh, yes, I'd like to know too :)

Joe Sam