Garbage collection vs manual memory management

Question

This is a very basic question. I will formulate it using C++ and Java, but it's really language-independent. Consider a well-known problem in C++:

struct Obj
{
    boost::shared_ptr<Obj> m_field;
};

{
    boost::shared_ptr<Obj> obj1(new Obj);
    boost::shared_ptr<Obj> obj2(new Obj);
    obj1->m_field = obj2;
    obj2->m_field = obj1;
}

This is a memory leak, and everybody knows it :). The solution is also well-known: one should use weak pointers to break the "refcount interlocking". It is also known that this problem cannot be resolved automatically in principle. It's solely programmer's responsibility to resolve it.

But there's a positive thing: a programmer has full control on refcount values. I can pause my program in debugger and examine refcount for obj1, obj2 and understand that there's a problem. I also can set a breakpoint in destructor of an object and observe a destruction moment (or find out that object has not been destroyed).

My question is about Java, C#, ActionScript and other "Garbage Collection" languages. I might be missing something, but in my opinion they

1. Do not let me examine refcount of objects
2. Do not let me know when object is destroyed (okay, when object is exposed to GC)

I often hear that these languages just do not allow a programmer to leak a memory and that's why they are great. As far as I understand, they just hide memory management problems and make it hard to solve them.

Finally, the questions themselves:

Java:

public class Obj
{
    public Obj m_field;
}

{
     Obj obj1 = new Obj();
     Obj obj2 = new Obj();
     obj1.m_field = obj2;
     obj2.m_field = obj1;
}

1. Is it memory leak?
2. If yes: how do I detect and fix it?
3. If no: why?

Answer 1

Managed memory systems are built on the assumption that you don't want to be tracing memory leak issue in the first place. Instead of making them easier to solve you try to make sure they never happen in the first place.

Java does have a lose term for "Memory Leak" which means any growth in memory which could impact your application, but there is never a point that the managed memory cannot clean up all the memory.

JVM don't use reference counting for a number of reasons

• it cannot handled circular references as you have observed.
• it has significant memory and threading overhead to maintain accurately.
• there are much better, simpler ways of handling such situations for managed memory.

While the JLS doesn't ban the use of reference counts, it is not used in any JVM AFAIK.

Instead Java keeps track of a number of root contexts (e.g. each thread stack) and can trace which objects need to be keeps and which can be discarded based on whether those objects are strongly reachable. It also provides the facility for weak references (which are retained as long as the objects are not cleaned up) and soft references (which are not generally cleaned up but can be at the garbage collectors discretion)

Answer 2

AFAIK, Java GC works by starting from a set of well-defined initial references and computing a transitive closure of objects which can be reached from these references. Anything not reachable is "leaked" and can be GC-ed.