OSNews

Where I work, based on the amount of permgen/out of memory errors we get on our Java server apps, I think somebody should re-invent memory management Note that I did not write, nor am I in charge of any of these apps. I'm just the poor schmuck who gets paged at 3am when one of these apps blows chunks, and I have to restart the f**king things. Time after time after time.

Our 'architects' have been looking into this for what seems like years, analyzing heap dumps and what not, and they usually just give the apps more permgen space, which fixes the problem ... for awhile, anyway. Then it's back to the same BS. So, I figure either Java absolutely blows ass, or we just need some new architects.

It's probably a combination of both. Though since the issue appears systematic, it's probably time to redraft the system with new criteria.

Are you trying to tell me that Java isn't running on pixie dust* that magically solves the halting problem??!!?!!

* Known as "ground coffee" to developers

Get new architects... Java works when stuff has been correctly designed which is easy to do. Bad thing about Java is that it is also easy to design things which are literally like things out of hell very easily.

Design that works in simple systems doesn't, and will never work if the amount of data to be handled by the system is multiple times more. It needs a complete redesign and it will cost money. Not as much as if it was written in some other language, but it still will cost you guys.

I will go for new architects.

Most of my consulting projects are done in JVM and .NET languages and I see often what I call "space station architecture" (I adopted the expression from someone else).

Designs done away from the reality, with thousand layers of abstraction, because it is cool.

Most of the performance problems we had to fix in some projects always have to do with architecture decisions.

- Not the right language/OS for the problem at hand;
- Lots of nicely abstracted layers;
- Communication between modules using the wrong type of communication protocols;
- Algorithms that aren't appropriate;
- Multiple remote calls to distributed systems;
- Data structures designed without regard for being GC friendly
- ...

For permgen space errors, indeed usually increasing it is the way to go. The permanent generation is used for 'static' information (using the word loosely, and apart from some exceptions which are unlikely to be relevant). It is expected to grow a bit after startup, up to the point where everything relevant for your application is loaded and the usage will no longer rise, no matter how much load/data you throw at the system.

If this is an application running inside a servlet container: do you ever restart/upgrade a component/application in the container without restarting the container, too? This is possible, but avoiding memory leaks (even in permgen, as each instance will have its own classloader) is tricky, and it's often acceptable to just restart the entire container.

For heap space errors, yeah, you need a developer to look at those.

You mention 'architects'. In case of memory errors (both permgen and heap), I'd suspect a programming error rather than an architecture error first. I'd suggest having a good developer ('craftsman' seems to be the hip term these days) look at it. He should be able to pinpoint what's the biggest culprit, and from there you can see whether it is possible to fix within the current architecture or that you really need structural changes.

Write a script to monitor those apps, so when they blowup they get automatically restarted. No need for you to babysit them at 3am.

Java does have memory management; however the memory management is done automatically with object creation and garbage collection.

This means that a lot of Java programmers aren't aware of it, and have no idea about things that improve memory management efficiency. Techniques like recycling objects and using stack (to avoid the overhead of allocating and freeing heap) may never enter a Java developers' mind. Basic things (like setting references to null when the object they refer to is no longer needed) may never happen.

If you make it possible for programmers to ignore memory management, then you shouldn't be surprised if these programmers don't do efficient memory management.

- Brendan

Don't do this!

These techniques used to be good up to Java 1.4 JVMs, but nowadays they do more harm than good to more modern GCs.