Dan Sugalski wrote:
At 8:58 PM +0100 11/6/02, Leopold Toetsch wrote:
If we want this, then lets have Parrot_{re,}allocate{,zeroed}. The allocate_string variants are ok with unzeroed mem already.
Which was my thought here. Things that care can ask for zeroed memory, which they may get anyway. (Or we may keep a big pool of zeroed memory around as it's cheaper to clean large blocks or something)
Appended is a test program that shows timings (i386 w rdtsc) and the limit, where malloc changes strategy to use mmap and returns zeroed memory.
The program does 3 allocations, globbers and frees mem between 2nd and 3rd and tests if memory in 3rd malloc is zeroed. It includes timing for memset as well.
A typical snippet for output is:
size 1.mal 2.mal 3.mal memset clean
16384 13297 9338 207 40246 **
32768 13310 9589 207 83827 **
65536 14164 10208 209 193610 **
131072 19951 12077 4085 0 0
So chunks with size >= 131072 are already zeroed due to mmap. With malloc.c this limit defaults to twice that size, but is configurable.
Parrot_allocate is currently allocating chunks of 32768 bytes, where zeroing mem is already expensive compared to allocating mmaped chunks.
Maybe it's possible to make a test out of this to see, if there is such a limit, where cleaned mmaped mem is returned and where this is.
leo
