Re: Should memory be washed?

[Dan Sugalski]

At 10:03 AM +0100 11/5/02, Leopold Toetsch wrote:

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.

This is one place where the current copying scheme is a win--we allocate zeroed pages from the OS, which often plays games with the MMU to do this really cheaply. That's one of the reasons lots of the older code assumes freshly allocated memory is zeroed.

I don't have a problem with guaranteeing zeroed memory, but it's not free. If we're going with a malloc-style allocator then I explicitly do *not* want to give guarantees of zeroed memory.

Arguably any code that assumes zeroed memory is broken, as it ought not be using any memory its not actually filled in data for.

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.

Buffers and PMCs should be sanitized when put on the free list. This should be done in the DOD sweep. Extended buffer headers should be zeroed past the end of the 'known' bits.

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).

There's a big difference between clean memory and clean headers. The headers we need to clean up ourselves, and there's a cost there we pay regardless. (Though keeping it in one tight part of the DOD code minimizes the cost somewhat)

--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk