I just finished debugging a re-invention of malloc and free - obviously, because I'm changing the value of brk myself, I'm not using mmap or the stdlib malloc or anything silly like that. When I test the program with MY functions, the value of brk after free is the same as it was before malloc. However, using the stdlib malloc, the value of brk is 0x21000 larger after free than it was before malloc, even though I'm only allocating around 25kb in memory.
Can someone explain to me why the fuck that would make sense?
Name:
Anonymous2009-03-22 3:15
>>1
Does your free implementation account for the register frame space that is consumed when overflowing a state buffer from data in your cache that contained BBCode? Try writing the implementation in a more BBCode-friendly language, such as BBCode.
Name:
Anonymous2009-03-22 4:32
Isn't sbrk a more appropriate function to use?
But I don't see the problem here. Is there any particular reason malloc shouldn't allocate a bit of extra memory, and not move the program break back?
I'm not saying there's a particular reason it shouldn't, I'm saying that I don't understand what is saved in that memory and why it needs to be saved if you don't have any data allocated to the heap. Is it just a record of data that used to be there? I don't see the use in that, it seems like a waste of memory. Seems to me it would only serve to help the program run out of memory more quickly.
Name:
Anonymous2009-03-22 6:32
how do you pronounce brk and sbrk?
for me:
brk = almost like a ribbit sound a frog makes, mainly made with the back of the throat
sbrk = sibruk
Get with the 21st century and use mmap() you fool. Is your professor making you use brk()?
Name:
Anonymous2009-03-22 13:59
>>4
Yes, extra space would be filled with garbage data. It wouldn't make your program run out of memory more quickly, since the extra allocated memory is still usable by your program. It would decrease overall free memory, but when people have hundreds or thousands of megabytes of memory, you can allocate a few kilobytes extra. I don't know what the malloc implementors were thinking, but I would guess that they made the assumption that a program that allocates 25kB of memory is likely to do it a few more times, so they go ahead and reserve the memory, planning to use it to satisfy future malloc calls. Perhaps it is faster not to call brk for every allocation, but rather to make a bigger allocation less often.
int i;
void * p;
for (i=10000000; i>0; i--) {
p = malloc(rand()&16383);
free(p);
}
Even though the standard library's allocator you're using will likely be pretty shitty, the performance of your homemade toy should give you a strong hint of how over your head this stuff is.
Name:
Anonymous2009-03-22 16:49
>>18
Why are you using a for loop you fuckin' retard.
>>23
Standard library: ./a.out 1.97s user 0.00s system 85% cpu 2.317 total
Custom malloc: ./a.out 0.24s user 0.00s system 87% cpu 0.424 total
LOL MY MALLOC IS 4X FASTER THAN YOURS GET OUT