Discussion on Go and D

[Sean Kelly]

On Apr 7, 2012, at 12:37 PM, Rainer Schuetze <r.sagitario at gmx.de> wrote:

> 
> 
> On 4/7/2012 8:26 PM, Sean Kelly wrote:
>> On Apr 7, 2012, at 9:45 AM, Rainer Schuetze<r.sagitario at gmx.de>  wrote:
>> 
>>> 
>>> 
>>> On 4/6/2012 6:20 PM, deadalnix wrote:
>>>> Le 06/04/2012 18:07, Andrei Alexandrescu a écrit :
>>>>> A few more samples of people's perception of the two languages:
>>>>> 
>>>>> http://news.ycombinator.com/item?id=3805302
>>>>> 
>>>>> 
>>>>> Andrei
>>>> 
>>>> I did some measurement on that point for D lately :
>>>> http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
>>>> 
>>> 
>>> I studied the GC a bit more and noticed a possible issue:
>>> 
>>> - memory allocations are aligned up to a power of 2<= page size
>>> - the memory area beyond the actually requested size is left untouched when allocating
>>> - when the memory is collected, it is also untouched
>>> - the marking of references during collection does not know the requested size, so it scans the full memory block
>>> 
>>> Result: When a collected memory block is reused by a smaller allocation, there might still be false pointers in the unused area.
>>> 
>>> When I clear this data, my first impression is that it has improved the situation, but not enough. I'll have to create some non-interactive test to verify.
>> 
>> The unused area is typically zeroed out on allocation. Check GC.mallocNoSync..
> 
> That's where I added it ;-) But in fact it is in malloc/calloc and a few more places, though I haven't checked whether all the other calls of mallocNoSync handle the situation correctly. Almost all calls are to malloc anyway, so my patch doesn't change anything.

Is it not already there?  Maybe it was removed in all the GC optimizations?  I certainly remember a memset(0) in there.