| 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." |
|
| RE: Other Java news today |
| By fretinator on 2012-09-14 20:19:55 |
| FYI, they posted an article on this yeaterday. |
 - Score: 2 |
| RE[4]: Memory management |
| By moondevil on 2012-09-14 21:00:21 |
|
Usually those actions tend to hinder the work of the more smarter GCs, that base their work in execution heuristics. Some places were you can get information about it. http://www.oracle.com/technetwor... http://www.infoq.com/presentatio... http://www.oracle.com/technetwor... |
| - Score: 4 |
| RE[2]: Other Java news today |
| By fran on 2012-09-15 13:42:25 |
|
LOL, i saw it yesterday and felt pretty stupid. My eyes just scanned the first two news item. |
| - Score: 2 |
| RE[4]: Memory management |
| By siride on 2012-09-15 15:24:22 |
| 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. |
| - Score: 3 |
| RE[5]: Memory management |
| By siride on 2012-09-15 15:26:21 |
| I would imagine that setting to NULL is unnecessary, because static analysis can tell the JVM or compiler whether the variable is used any more, and if it's not, it can be GC'ed, whether it's set to NULL or not. Setting to NULL is only valuable in refcounted GC implementations, and neither Java nor .NET use such a scheme. |
| - Score: 2 |
| RE: reading the article |
| By deathshadow on 2012-09-15 17:09:29 |
| Agreed, felt like it should have "This article is a stub" text on it. Just as I felt like it was starting to get down to saying something meaningful, it just ends... |
| - Score: 2 |
| RE[6]: Memory management |
| By raboof on 2012-09-15 19:18:14 |
|
> static analysis can tell the JVM or compiler whether the variable is used any more, and if it's not, it can be GC'ed, whether it's set to NULL or not. This is true, but only for local variables. For fields, there may be cases where an object needs to be kept alive, but one of its fields can be discarded, so setting it to NULL is advantageous. Static analysis won't help there, taking into account Java has a reflection API. Indeed, though, such cases are probably rare, and a form of code smell in the first place. |
| - Score: 2 |
| RE[7]: Memory management |
| By siride on 2012-09-15 22:09:06 |
|
Yes, you are correct. I was only thinking about local variables. There is little need, however, to have fields that would become unused while the owning object remained in use. In such a case, they shouldn't be fields. That's not to say that people won't do the wrong thing. I assume that's what you were talking about with your code smell comment. |
| - Score: 2 |
| RE[8]: Memory management |
| By raboof on 2012-09-15 22:19:16 |
|
> There is little need, however, to have fields that would become unused while the owning object remained in use. In such a case, they shouldn't be fields. That's not to say that people won't do the wrong thing. I assume that's what you were talking about with your code smell comment. Yes, exactly. |
| - Score: 2 |
| RE[4]: Memory management |
| By snowbender on 2012-09-16 12:10:46 |
|
> > 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. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |