Discussion on Go and D

[Dmitry Olshansky]

On 07.04.2012 18:43, Rainer Schuetze wrote:
>
>
> On 4/7/2012 8:24 AM, Dmitry Olshansky wrote:
>> On 07.04.2012 2:08, Rainer Schuetze wrote:
>>>
>>>
>>> On 4/6/2012 8:01 PM, Walter Bright wrote:
>>>> On 4/6/2012 10:37 AM, Rainer Schuetze wrote:
>>>>> I hope there is something wrong with my reasoning, and that you could
>>>>> give me
>>>>> some hints to avoid the memory bloat and the application stalls.
>>>>
>>>> A couple of things you can try (they are workarounds, not solutions):
>>>>
>>>> 1. Actively delete memory you no longer need, rather than relying on
>>>> the
>>>> gc to catch it. Yes, this is as unsafe as using C's free().
>>>
>>> Actually, having to deal with lifetime issues myself takes away the
>>> biggest plus of the GC, so I am a bit reluctant to do this.
>>>
>>
>> How about this:
>> http://blog.thecybershadow.net/2010/07/15/data-d-unmanaged-memory-wrapper-for-d/
>>
>>
>>
>> Or you can wrap-up something similar along the same lines.
>>
>
> Thanks for your and other's hints on reducing garbage collected memory,
> but I find it hard to isolate larger blocks of memory for manual
> management. Most of the structs and classes are rather small.
>

Then clearly you need a custom allocator/allocation scheme. Most likely 
a mark/release or a free list kind of thing. Like say TempAlloc by 
David. As standard allocator design is still in motion you'd have to do 
your own thing ATM.

Parsers and lexers are notable examples where doing custom allocation 
pays off nicely.

> I'm rather unhappy to sell D with the hint "Go back to manual memory
> management if you need more than 64MB of memory and want your
> application to be responsive."

I totally understand this sentiment, and unless GC improves by an order 
of magnitude it is not going to work well with large to medium-scale 
apps. Particularly long running ones, I once had been running VisualD 
for about 16 hours straight (back in the days of GSOC 2011) ;)

-- 
Dmitry Olshansky