Memory allocation faile on string concat

[Steven Schveighoffer]

On Thu, 11 Nov 2010 07:42:36 -0500, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Wed, 10 Nov 2010 23:33:58 -0500, Xie <Xiemargl at 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