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 535087
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Memory management
by Brendan on Fri 14th Sep 2012 17:36 UTC in reply to "RE[2]: Memory management"
Brendan
Member since:
2005-11-16

"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

Reply Parent Score: 2

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

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.

Reply Parent Score: 4

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

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.

Reply Parent Score: 2

RE[4]: Memory management
by moondevil on Fri 14th Sep 2012 21:00 in reply to "RE[3]: Memory management"
moondevil Member since:
2005-07-08

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/technetwork/java/hotspotfaq-138619.html#gc_po...

http://www.infoq.com/presentations/Understanding-Java-Garbage-Colle...

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

Reply Parent Score: 4