On Apr 7, 2012, at 12:37 PM, Rainer Schuetze <r.sagita...@gmx.de> wrote:
> > > On 4/7/2012 8:26 PM, Sean Kelly wrote: >> On Apr 7, 2012, at 9:45 AM, Rainer Schuetze<r.sagita...@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.
