| 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." |
|
| reading the article |
| By aargh on 2012-09-14 08:33:10 |
| Reading the article felt like: OK nice intro, finally the interesting part "When things do not go as per the plan"... Where's the next page button? What the hell? The End. |
 - Score: 6 |
| RE: reading the article |
| By shinkou on 2012-09-14 14:45:48 |
| It looks like I'm not the only one. The fun part is missing... do we have to pay for the remaining pages? |
| - Score: 1 |
| Other Java news today |
| By fran on 2012-09-14 15:40:11 |
|
I stumbled on this cool piece of news. Doubt OSnews will post two Java news pieces back to back so i just post it here:) Google releases Java to Objective C translator http://www.h-online.com/open/new... Edited 2012-09-14 15:40 UTC |
| - Score: 1 |
| RE[3]: Memory management |
| By Brendan on 2012-09-14 17:36: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. Would you mind elaborating? I can't see how these things can cause more harm than good (regardless of language or VM). - Brendan |
| - Score: 2 |
| RE[2]: Memory management |
| By raboof on 2012-09-14 17:39:18 |
|
> 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. 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. |
| - Score: 4 |
| RE[4]: Memory management |
| By raboof on 2012-09-14 17:52:16 |
|
> I can't see how these things (recycling objects and using stack, like setting references to null when the object they refer to is no longer needed) can cause more harm than good (regardless of language or VM). I agree with moondevil that these kinds of 'optimizations' are a really bad idea. The most important reason is they will make your code more complicated, and thus harder to maintain and more likely to contain bugs. Recycling objects: this might be useful in languages where the construction of an object corresponds directly to a malloc call. Java's memory manager is smarter than that, so creating and destroying many objects is not really a performance problem (anymore - this used to be slow on older JVM's, like 1.4 old). Stack: not a bad idea per se, but won't help much as Java only holds primitives on the stack, not objects. It's still a good idea to prefer local variables to fields, but for other reasons than performance. Setting references to null: This might be useful in a situation where you have a mutable reference to a big data structure which you don't need anymore after a certain point. Such situations should be rare, and I'd suspect the code could/should be refactored in another way that would prevent the big structure to be kept alive for too long. Of course it's hard to talk about such things without concrete examples, and I'm not giving any either, but I hope this provides some ideas. |
| - Score: 4 |
| RE[3]: Memory management |
| By raboof on 2012-09-14 17:59:11 |
|
> "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 :). |
| - Score: 2 |
| RE[3]: Memory management |
| By WorknMan on 2012-09-14 18:06:29 |
|
> 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. |
| - Score: 0 |
| RE: Other Java news today |
| By Tuishimi on 2012-09-14 18:08:47 |
| Cool! |
| - Score: 2 |
| RE[3]: Memory management |
| By butters on 2012-09-14 18:33:22 |
|
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?" |
| - Score: 4 |
| News | Features | Interviews |
| Blog | Contact | Editorials |