As referenced in Ulrich Drepper Memoery Article Series, here is the sixth part in this series, now available for non-subscribers of LWN:
Memory part 6: More things programmers can do
Believe me or not, but we thank the mysterious powers of the Universe for Ulrich Drepper every day. Don’t you? At least, you do if you use glibc. And you probably do. Uli has recently shown his deft style at touching both ends of the spectrum of programmers (newbies to oldsters) with a video series on Red Hat Magazine for those of us still grasping the details of a memory stack or needing a cluestick to remember to pay attention to the basics and the lessons learned.
We were seriously scooped recently when the venerated LWN began publishing a seven part series from Uli. Called What every programmer should know about memory, it is a thorough grounding in memory dynamics on modern hardware running Linux.
» Read more
This tip article is edited and republished from the original source.
by Michael Juntao Yuan and Clebert Suconic
Memory leaks are one of the most common bugs in software engineering. A memory leak is created when a developer allocates memory space for an object but forgets to free the memory when the object is no longer in use. Memory leaks are hard to find. But they can cause application crashes, poor performance, or even open security holes if they are not fixed.
Compared with native programming languages such as C and C++, one of the major advantages of the Java platform is that Java has a built-in defense mechanism against memory leaks. The Java Virtual Machine (JVM) runs a Garbage Collector (GC) service periodically to free up memory for objects no long used by the application. So, the developer does not have to remember to the free the objects manually. Automatic memory management in Java is a great feature for improving developer productivity and application quality.
