Explicitly tagging an object as unused

843853

Just read an article on gc tuning (http://www-106.ibm.com/developerworks/java/library/j-perf06304/?ca=dgr-lnxw07BlogFix)
where memory leaks are caused by the so called "unintentionally retained objects".
Currently, detecting memory leak in Java is done using memory profiler to monitor
memory usage and select which objects are suspected to cause of memory leaks.
Then, the programmer must decide/guess which of the suspected objects really cause
memory leaks.

Is it worthed to provide an API that explicitly tags an object as unused, so that memory
profilers can find which objects are 100% the cause of memory leak? The notion of this
API is similar to free in C, however, this API does not affect the decision made by gc
regarding the reclaimability of an object, nor does it force gc to reclaimed the object.
Object marked by this API means "I'm no longer needed by the user/program/algorithm.
Hence, I should be able to be reclaimed by gc. If gc deemed I'm still referenced, this
means the programmers make mistakes, and thus, they must fix the program".

843853

Just read an article on gc tuning where memory leaks are caused by the so called "unintentionally retained objects".

Quote: From the final memory profile (Figure 3), with the major memory leak eliminated, we can see that there still is another "low grade" leak, but this leak is small enough that it can be ignored until the next release.

If you are getting memory management advice from articles by people who are happy to release software that they know is leaky, then you're in trouble. (OK, so my background is flight control software where leaks would be a matter of life and death, but these people seem to have no sense of personal honour.)

Currently, detecting memory leak in Java is done using memory profiler to monitor memory usage and select which objects are suspected to cause of memory leaks.

Only do what is necessary to perform the required functionality. If having a reference to an object is functionally necessary, then that reference is required and will not be a leak. If you have a reference that is not required for the functionality, then you shouldn't have that reference any more. Cases where performance requires that a value be cached in case it is may be needed are already catered for with the WeakReference and SoftReference APIs.

Is it worthed to provide an API that explicitly tags an object as unused, so that memory profilers can find which objects are 100% the cause of memory leak?

No, for the same reason that there is no goto in Java. If you are writing software that is so convoluted you don't know what objects are referencing each other, adding an API that encourages you do that more will not help you.

If gc deemed I'm still referenced, this means the programmers make mistakes, and thus, they must fix the program".

If you are debugging badly written code, and do not have access to a static analysis tool which will tell you where your objects are being referenced, then you have the option of creating a reference queue and a phantom reference to your suposedly unreferenced object, clearing all references in your algorithm, forcing gc, and then asserting that the phantom reference was cleared.


Pete