Discussion on Go and D

[Rainer Schuetze]

On 4/8/2012 12:04 AM, Timon Gehr wrote:
> On 04/07/2012 04:43 PM, 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.
>>
>
> As you apparently just re-parse the whole source and throw the old AST
> away, wouldn't it be rather simple? You could just create a region
> allocator and free all the memory at once after the re-parse.

If you only use the syntax error highlighting feature that might work. 
As soon as semantic analysis kicks in modifications on a copy of the 
parse tree are done lazily, and as symbols get resolved, references into 
other trees are remembered. It can get rather involved to figure out 
when it is safe to delete a memory block manually.

The region allocator has the advantage that it does not need the 
alignment to the power of 2 for each allocation, so memory could be 
saved, too.

I guess, I'll try something along the line with some additional 
functions to avoid bad references after deletion.

>
>> 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 think it is actually awesome that manual memory management is possible.