Linked by Thom Holwerda on Fri 14th Sep 2012 02:30 UTC, submitted by MOS6510
Java "As a typical Java developer I never monitored the memory usage of my application apart from following typical best practices like closing the connections, streams etc. Recently we were struck with few issues in our JBoss servers that I had to dig in to the memory management."
Thread beginning with comment 535018
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Memory management
by moondevil on Fri 14th Sep 2012 06:49 UTC in reply to "RE: Memory management"
moondevil
Member since:
2005-07-08

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
- ...

Reply Parent Score: 3

RE[3]: Memory management
by raboof on Fri 14th Sep 2012 17:59 in reply to "RE[2]: Memory management"
raboof Member since:
2005-07-24

"space station architecture" - Designs done away from the reality, with thousand layers of abstraction, because it is cool.

Hmm, I'd expect 'space station architecture' to be a positive classification: if you design something for a space station, you better design it well, because you can't easily go up there and fix it later ;) .

Reply Parent Score: 2

RE[4]: Memory management
by zima on Fri 21st Sep 2012 23:59 in reply to "RE[3]: Memory management"
zima Member since:
2005-07-06

Well, that's not strictly what really happens...

NVM that our stations are more or less mostly testbeds for deep space vessels (with the convenience of, yes, being relatively easy to reach quickly; or to evacuate...), failures are common, as is experimenting with proper approaches. Also:

a) ISS is really... Mir-2 (as in, the core module of ISS is practically identical to Mir, because it was built concurrently with it, as a backup - it even had "Мир-2" painted on it, when it was kept in storage; the whole Russian section is generally what was supposed to be the entirety of Mir-2, also where main computers, engines, and such of the station are - the rest is, sort of, an attached cargo). It wasn't so much about designing things, more using what's at hand and with minimum of costs...

b) the "non-Mir" part of the station was largely crippled in its design, with how it had to be nominally launched by the STS, so as to give that horribly wasteful contraption some pretend-purpose (really, a spacecraft wasting most of launched mass on airframe? ...and, considering that we did automatic rendezvous already in the 60s, the Shuttle was conceptually obsolete before seriously getting on the drawing boards; now, with STS finally out of the way, there's even a fairly inexpensive project of attaching small orbital tugs to some of the ISS modules remaining in-storage, to launch them like that on efficient expendable rockets)

Overall, assuming failures and building in lots of redundancies and/or planning for contingencies seems to be more the way.

Edited 2012-09-22 00:19 UTC

Reply Parent Score: 2

RE[3]: Memory management
by WorknMan on Fri 14th Sep 2012 18:06 in reply to "RE[2]: Memory management"
WorknMan Member since:
2005-11-13

I will go for new architects.


I figured people would say that, because either on the server or desktop, no matter how shitty Java apps run (which seems to be most of the time), it never appears to be Java's fault.

Reply Parent Score: 0

RE[4]: Memory management
by snowbender on Sun 16th Sep 2012 12:10 in reply to "RE[3]: Memory management"
snowbender Member since:
2006-05-04

"I will go for new architects.


I figured people would say that, because either on the server or desktop, no matter how shitty Java apps run (which seems to be most of the time), it never appears to be Java's fault.
"

The Permgen space is a part of the Java memory that is used for storing definitions of classes. Now, when working with Java application servers (e.g. JBoss) each web application that is running on the server uses its own classloader(s). The class loader is used to load the classes that are used inside the web application. The classloader itself is stored in the permgen space together with all the class definitions it loads.

One issue here is that the more web applications run on your application server, the more permgen space you will need. This is a simple fact and the default space reserved for permgen space is not really enough for an application server with lots of applications on it.

The other issue is that when a web application is unloaded, also the class loader that was connected to it should be freed. This is actually the responsibility of the container, that is the application server itself. The problem is that some application servers do not correctly release those class loaders and that can also lead to the problems you mention.

Is that the architects fault? Nope, not really. On the other hand, as an architect, you should know those things and take them into account when building systems. As an architect, you should really know how classloaders work and how they are linked together.

Reply Parent Score: 2

RE[3]: Memory management
by butters on Fri 14th Sep 2012 18:33 in reply to "RE[2]: Memory management"
butters Member since:
2005-07-08

I don't know. Java is a language that invites hotshot "architects" to devise Rube Goldberg machines. Factories that create factories that create classes. Of course they'll want to model it all in UML first, because that's how good code happens. If you bring in new Java architects and give them enough rope, they'll come up with a way to make things more complex than they were before.

Once I was contracted to rewrite a troubled Python application, and after browsing the codebase for an hour, I remarked the poor guy who was maintaining this thing: "This code looks like it was written by some hotshot Java developer". And he said: "How did you know that?"

Reply Parent Score: 4

RE[4]: Memory management
by siride on Sat 15th Sep 2012 15:24 in reply to "RE[3]: Memory management"
siride Member since:
2006-01-02

On the other side of the coin, you have people who code like it's 1965 and there is only 2K of RAM available. Every algorithm is a labyrinth, all in one function, usually, with undocumented shortcuts and hacks.

Reply Parent Score: 3