On Thu, 11 Nov 2010 07:42:36 -0500, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Wed, 10 Nov 2010 23:33:58 -0500, Xie <xiema...@gmail.com> wrote:
OK, this actually makes sense to me.
It's a manifestation of this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=3929
I'm think - it's truth but not at all.
Sorry, but i'm give incomplete data.
My example run fine, when benchmark(1), (2), but not 10.
This means, that memory not collected _between_ calls.
Yes, this is what the bug report is about -- the memory is not collected
even though there are no references left, because the cache used to
speed up appending still has a reference.
OK, so I have actually implemented a fix for bug 3929. Essentially, the
cache will no longer hold hostage the data that was being appended.
However, I have found that this *still* doesn't fix the problem. Even
though the cache no longer holds the memory as allocated, the example does
something that we can't really get around.
When you allocate a very very large block of data (in this case 1/20 of
your address space), it is inevitable with a conservative GC that this
data never gets collected. Why? Because the stack is scanned
conservatively, and the chances that some 4-bytes of data looks like it
points to the space is very high.
So in order to fix this, we would not only need precise heap scanning, but
*also* precise stack scanning, and precise TLS/global data scanning.
But I'm still going to check this in to fix the bug, because it does seem
to help with smaller blocks.
I'll post more on the main newsgroup on this issue.
-Steve
