title: Garbage collection vs manual memory management
body: <p>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++:</p>
  
  <pre><code>struct Obj
  {
      boost::shared_ptr&lt;Obj&gt; m_field;
  };
  
  {
      boost::shared_ptr&lt;Obj&gt; obj1(new Obj);
      boost::shared_ptr&lt;Obj&gt; obj2(new Obj);
      obj1-&gt;m_field = obj2;
      obj2-&gt;m_field = obj1;
  }
  </code></pre>
  
  <p>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.</p>
  
  <p>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).</p>
  
  <p>My question is about Java, C#, ActionScript and other "Garbage Collection" languages. I might be missing something, but in my opinion they</p>
  
  <ol>
  <li>Do not let me examine refcount of objects</li>
  <li>Do not let me know when object is destroyed (okay, when object is exposed to GC)</li>
  </ol>
  
  <p>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.</p>
  
  <p>Finally, the questions themselves:</p>
  
  <p>Java:</p>
  
  <pre><code>public class Obj
  {
      public Obj m_field;
  }
  
  {
       Obj obj1 = new Obj();
       Obj obj2 = new Obj();
       obj1.m_field = obj2;
       obj2.m_field = obj1;
  }
  </code></pre>
  
  <ol>
  <li>Is it memory leak?</li>
  <li>If yes: how do I detect and fix it?</li>
  <li>If no: why?</li>
  </ol>