Page 4 sur 4

Re: ndless memory map

Message non luPosté: 06 Juil 2020, 16:39
de nspiredev500
If you aren't willing to pay the size cost, maybe consider the runtime-cost.
I made a small example program that uses the linker to wrap custom functions around malloc and free.
It keeps track of all alocations in a resizeable array and provides a function
Code: Tout sélectionner
void deallocate_exit(int)
to exit the program.
It doesn't double-free anything and doesn't leak any memory from my tests.
It uses "-Wl,-wrap=malloc -Wl,-wrap=free" as LDFLAGS.
It also seems to work with smart pointers and new.

For now it searches the entire array for a free place or for the entry to free.
I'm sure you could optimise this by making separate buckets of allocations depending on the address.
Should I optimize this and make it into a library?

Re: ndless memory map

Message non luPosté: 06 Juil 2020, 16:55
de Adriweb
Hmm, good job :)

Re: ndless memory map

Message non luPosté: 07 Juil 2020, 11:35
de nspiredev500
I measured the performance of my wrapper on my calculator.
Code: Tout sélectionner
for (volatile uint32_t i = 0;i<1000000;i++) // so this doesn't get optimized out
{
   volatile void* p = malloc(10); // so this doesn't get optimized out
   free(const_cast<void*>(p));
}
The binary size overhead is 8K.
The time overhead is 2.56 milliseconds.
This is the best-case scenario, as the lookup time is almost instant.
But when the list is already filled with 1000 entries, searching through it becomes really slow:
Only 100000 iterations, 14 seconds slower with the wrapper.

So either you don't have many objects or I have to optimize this a little.

EDIT: I put allocations into buckets, now it's faster, but depends on the size of your allocations, the heap layout at the time and the granularity of the buckets

Re: ndless memory map

Message non luPosté: 07 Juil 2020, 20:12
de parisse
Sorry for responding a little late, but I don't think I need a custom malloc. Shutdown is called from a getkey call, it was not that hard to return a KEY_SHUTDOWN code there and propagate to the caller when possible, until main is reached. I also set a shutdown flag to true when propagation to upper frames was not possible (more precisely would be too complicated to implement), so that exit is called from a next getkey.