| News | Features | Interviews |
| Blog | Contact | Editorials |
| Java memory model simplified |
| By Thom Holwerda, submitted by MOS6510 on 2012-09-14 02:30:57 |
| "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." |
|
| Memory management |
| By kwan_e on 2012-09-14 02:45:26 |
|
In Java? I was [ts]old they uninvented memory management! |
 - Score: 4 |
| RE: Memory management |
| By WorknMan on 2012-09-14 02:52:33 |
|
> I was [ts]old they uninvented memory management! 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 :P 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. |
| - Score: 9 |
| RE[2]: Memory management |
| By satsujinka on 2012-09-14 03:10:04 |
| It's probably a combination of both. Though since the issue appears systematic, it's probably time to redraft the system with new criteria. |
| - Score: 3 |
| Comment by some1 |
| By some1 on 2012-09-14 03:13:02 |
| Eh? The guy doesn't even know what the difference is between memory management (that's what he's talking about) and memory model (which is memory access from threads, see http://en.wikipedia.org/wiki/Jav...). |
| - Score: 5 |
| RE: Memory management |
| By Brendan on 2012-09-14 03:33:53 |
|
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 |
| - Score: 6 |
| RE[2]: Memory management |
| By kwan_e on 2012-09-14 06:10:11 |
|
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 |
| - Score: 4 |
| Comment by wigry |
| By wigry on 2012-09-14 06:20:57 |
| There are fundamentally different GC strategies producing fundamentally different performance and any serious Java developer must be aware of them. |
| - Score: 2 |
| RE[2]: Memory management |
| By Dekonega on 2012-09-14 06:43:50 |
|
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. |
| - Score: 4 |
| RE[2]: Memory management |
| By moondevil on 2012-09-14 06:49:20 |
|
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 - ... |
| - Score: 3 |
| RE[2]: Memory management |
| By moondevil on 2012-09-14 06:50:50 |
|
> 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. 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. |
| - Score: 3 |
| News | Features | Interviews |
| Blog | Contact | Editorials |