title: Managed memory leaked by C# iterator
body: <p>I have a class that generates DNA sequences, that are represented by long strings. This class implements the <code>IEnumerable&lt;string&gt;</code> interface, and it can produce an infinite number of DNA sequences. Below is a simplified version of my class:</p>
  <pre><code>class DnaGenerator : IEnumerable&lt;string&gt;
  {
      private readonly IEnumerable&lt;string&gt; _enumerable;
  
      public DnaGenerator() =&gt; _enumerable = Iterator();
  
      private IEnumerable&lt;string&gt; Iterator()
      {
          while (true)
              foreach (char c in new char[] { 'A', 'C', 'G', 'T' })
                  yield return new String(c, 10_000_000);
      }
  
      public IEnumerator&lt;string&gt; GetEnumerator() =&gt; _enumerable.GetEnumerator();
      IEnumerator IEnumerable.GetEnumerator() =&gt; GetEnumerator();
  }
  </code></pre>
  <p>This class generates the DNA sequences by using an <a href="https://docs.microsoft.com/en-us/dotnet/csharp/iterators" rel="noreferrer">iterator</a>. Instead of invoking the iterator again and again, an <code>IEnumerable&lt;string&gt;</code> instance is created during the construction and is cached as a private field. The problem is that using this class results in a sizable chunk of memory being constantly allocated, with the <a href="https://docs.microsoft.com/en-us/dotnet/api/system.gc" rel="noreferrer">garbage collector</a> being unable to recycle this chunk. Here is a minimal demonstration of this behavior:</p>
  <pre><code>var dnaGenerator = new DnaGenerator();
  Console.WriteLine($&quot;TotalMemory: {GC.GetTotalMemory(true):#,0} bytes&quot;);
  DoWork(dnaGenerator);
  GC.Collect();
  Console.WriteLine($&quot;TotalMemory: {GC.GetTotalMemory(true):#,0} bytes&quot;);
  GC.KeepAlive(dnaGenerator);
  
  static void DoWork(DnaGenerator dnaGenerator)
  {
      foreach (string dna in dnaGenerator.Take(5))
      {
          Console.WriteLine($&quot;Processing DNA of {dna.Length:#,0} nucleotides&quot; +
              $&quot;, starting from {dna[0]}&quot;);
      }
  }
  </code></pre>
  <p>Output:</p>
  <pre class="lang-none prettyprint-override"><code>TotalMemory: 84,704 bytes
  Processing DNA of 10,000,000 nucleotides, starting from A
  Processing DNA of 10,000,000 nucleotides, starting from C
  Processing DNA of 10,000,000 nucleotides, starting from G
  Processing DNA of 10,000,000 nucleotides, starting from T
  Processing DNA of 10,000,000 nucleotides, starting from A
  TotalMemory: 20,112,680 bytes
  </code></pre>
  <p><a href="https://dotnetfiddle.net/jZIfC3" rel="noreferrer">Try it on Fiddle</a>.</p>
  <p>My expectation was that all generated DNA sequences would be eligible for garbage collection, since they are not referenced by my program. The only reference that I hold is the reference to the <code>DnaGenerator</code> instance itself, which is not meant to contain any sequences. This component just generates the sequences. Nevertheless, no matter how many or how few sequences my program generates, there are always around 20 MB of memory allocated after a full garbage collection.</p>
  <p><strong>My question is:</strong> Why is this happening? And how can I prevent this from happening?</p>
  <p>.NET 6.0, Windows 10, 64-bit operating system, x64-based processor, Release built.</p>
  <hr />
  <p><strong>Update:</strong> The problem disappears if I replace this:</p>
  <pre><code>public IEnumerator&lt;string&gt; GetEnumerator() =&gt; _enumerable.GetEnumerator();
  </code></pre>
  <p>...with this:</p>
  <pre><code>public IEnumerator&lt;string&gt; GetEnumerator() =&gt; Iterator().GetEnumerator();
  </code></pre>
  <p>But I am not a fan of creating a new enumerable each time an enumerator is needed. My understanding is that a single <a href="https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.ienumerable-1" rel="noreferrer"><code>IEnumerable&lt;T&gt;</code></a> can create many <a href="https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.ienumerator-1" rel="noreferrer"><code>IEnumerator&lt;T&gt;</code></a>s. AFAIK these two interfaces are not meant to have an one-to-one relationship.</p>