Reason #113 - Why I Have Issues with Java

Scott Sellers (of Azul fame) has a post up on GigaOm about Java memory issues.  To quote

An improvement in the Java virtual machine (JVM) can make a world of difference.

E-commerce application failures can often be sourced back to limitations of conventional JVMs, which constrain application resources and make it challenging to scale apps beyond a few gigabytes of memory, which can effect performance under load.

Conventional JVMs also suffer from stop-the-world pauses because the JVM needs to clean up its internal memory, the impact of which causes applications to freeze and become unresponsive.

Programmers must tune Java to work around the JVM’s limited scalability and very carefully manage the amount of memory a given application uses. For e-tailers, this is bad news, because e-commerce applications must handle users loads that are never static and require more memory for each user and transaction to ensure consistent user response times and high sustained throughput.

What if e-tailers had a JVM that could elastically manage application memory allocation before it ever became a limitation?

The Java runtime (i.e. the JVM) would sense the demands of the application in real-time and grow its memory beyond the static limitation of conventional JVMs and never encounter those nasty stop-the-world pauses. Rather than freezing during demand surges and peak requirements, e-commerce applications would stay highly available and responsive. Such a JVM would enable the Java runtime to be consistent regardless of sales volume.

 So yeah, this is pretty accurate, and pretty much describes all the chaos that I've dealt with in the past with our production telecommunications platform running flat-out, at scale, where we spent aeons figuring out that magical set of metrics for startup memory, heap, load, scale-factors, tint-control, astrological signs, etc. that would keep things from crashing unexpectedly.
Add to that the monitoring, alarming, tracking, and general care/feeding associated with seeing exactly how things were going on every node, well, it was a bit of a righteous pain.
Mind you, this is pretty true of a lot of environments out there.  The erlang VM (my environment of choice) has *its* own memory issues, but, and this is key, it is pretty damn predictable.
And that, in the end, is my main quibble w/ Java - it is anything but predictable.

Oh I know, pretty much everything above has the obvious response along the lines of "But if you just do XXX then you don't need to worry about YYY", to which I respond with Mahesh's Tenth Law - "Complexity never goes away, it just moves around the plate.
I'm pretty serious about that - the environment you choose pretty much constrains the level of complexity that you will be dealing with.  Attempts to throttle these in one arena will, inevitably, move it around to a different area.

Heres to hoping that somebody (Oracle? maybe?) actually does something about this.

Note:  Yes, I am referring to Java - The Environment, not Java - The Language, or even Java - The Class Libraries. Those are subjects of a completely different rant, something along the lines of Why OO Sucks, but then that would just be trolling wouldn't it?