Well that's total nonsense.
JVM was optimized for multicore processing in Java 6 and Java 7 and the IBM J9 jvm works very well in concurrency. Look at some of my posts on configuring subsystems for java performance on the Java400 archives.
<div>-------- Original message --------</div><div>From: Nathan Andelin <nandelin@xxxxxxxxx> </div><div>Date:10/21/2014 11:32 AM (GMT-06:00) </div><div>To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> </div><div>Subject: Re: JVM CPU queueing </div><div>
</div>>
Is it normal JVM's to spend a large percentage of time CPU queueing?
Yes it's normal, and I believe we've seen this in virtually every published
Java benchmark on virtually every hardware / OS platform, no matter how
many threads a JVM / application server may be configured to run
concurrently. The only way for a JVM to fully utilize a multi-core system
is to run multiple JVM / application server instances, and to deploy your
applications across each instance.
IBM schentist Ronald Luijten commented in the September 2014 issue of IBM
Systems Magazine, "We also have the multi-core programming wall. All of our
computer science students learn how to program in Java, which doesn't
support multi-cores at all. Intel may put 128 cores on a chip, but people
coming out of universities are only going to use one of them."
So if you're going to switch your application architecture from the native
virtual machine to a JVM, I would recommend that you still use RPG to
implement data validation, RI constraints, and business rules - rather than
moving that kind of logic into a JVM environment. Use the JVM if you will
for browser I/O.
Nathan.
midrange.com
