Chris's Wiki :: blog/programming/GoSlicesMemoryLeak Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/GoSlicesMemoryLeak?atomcommentsDWiki2017-10-11T16:06:22ZRecent comments in Chris's Wiki :: blog/programming/GoSlicesMemoryLeak.By Chris Siebenmann on /blog/programming/GoSlicesMemoryLeaktag:CSpace:blog/programming/GoSlicesMemoryLeak:b3f4ed6c4e0e7758fc798a72725b41bfaf4d165fChris Siebenmann<div class="wikitext"><p>Go has the same issue for any slice with an explicit backing array (or
to put it another way, any slice of a real existing thing). For example,
if you read a file into a big string and then parse it using the obvious
approach of slices to pull out substrings for symbols and text and so on,
you may wind up with little sections of the resulting parse keeping the
entire big string alive (which is I think the same issue in Java).</p>
<p>What's novel about this situation is that the slice is backed by an
anonymous array, one that you never created explicitly and that's just
materialized as needed by the built-in <code>append()</code> operation. With no
explicitly created backing array, it's not entirely natural to remember
that it's there and that it doesn't shrink when the slice does; it's
very easy to think of the slice as the only thing here.</p>
<p>(And in a sense the slice is the only thing. The slice is the abstraction
that people deal with; the backing array is in a sense just a runtime
implementation detail.)</p>
</div>2017-10-11T16:06:22ZBy skeeto on /blog/programming/GoSlicesMemoryLeaktag:CSpace:blog/programming/GoSlicesMemoryLeak:77fd27d8ea3529aeb8ac531bf38b89c67b693841skeetohttp://nullprogram.com/<div class="wikitext"><p>If I remember correctly, Java has had a similar issue with its substrings. For example, parsers must make copies of substrings if it intends to hold onto them (identifiers, etc.), since otherwise the substring holds a reference to the original, large input buffer.</p>
</div>2017-10-10T12:37:03Z