Peter Gibbs wrote:
What is the official position with respect to laundry services in the Parrot memory allocation code?
I would strongly urge for calloc()ed memory as done now.
Some code assumes that the memory returned by Parrot_allocate
and its cousins will be pre-washed, while other code does its own
laundry.
By just deleting all this x->y = 0 and memsets all over the place we would save hundreds of source lines.
... The same applies to 'bufferlike' headers - the buffer fields will always be initialised, but the remainder of the allocated header is sometimes assumed dirty, and sometimes assumed clean. (The latter currently breaks recycling of bufferlike headers)
Ah, this is the reason - well spotted. I did try to add_free these buffers, with a lot of breaking tests in list and hash, which are the main users of buffer_likes. Cleaning the part beyond a plain Buffer in dod.c before add_free_buffer would do the trick I presume?
Making the allocation routines responsible for providing clean
memory simplifies things for everybody else, but with a potential
performance cost.
Yes to first - but I don't think its a performance penalty. Almost all used fields have to be cleaned first (and are explictely currently).
The only exception is currently Parrot_rellocate_string in res_lea.c which doesn't clean the realloced part - and this doesn't harm.
I think, we could go for uncleaned memory in strings and res_lea. The allocator in resources uses cleaned memory pools, so this wouldn't change.
leo
