[fpc-devel] CMem allocator memory alignment experiment

Karoly Balogh (Charlie/SGR) charlie at scenergy.dfmk.hu
Tue Nov 18 20:33:38 CET 2014


I think there are several issues with the cmem memory allocator. The main
issue that it "breaks" the underlying malloc() memory alignment, by adding
a four/eight byte size value to the start of each block for the sole
reason to be able to throw Runtime Error 204 in case someone tries to free
a block with the wrong size.

At least on Linux, malloc() is documented to align to 64 bit on 32 bit and
128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that
to 4 bytes and 8 bytes, respectively.

This causes multiple performance and other issues, especially on
processors which require stricter alignment (most ARM CPUs, but also x86
with SSE, etc).

I created a cmem variant, which does 16 byte alignment of the returned
memory blocks, just like FPC's own Heap Manager does:


However, when I build FPC with this cmem16 allocator, the compiler
explodes. Also it fails with other larger parts of code, and I'm unsure
why, I spent a few days debugging, but I couldn't find the issue. Ideas?

I wanted to contribute the code to the FPC SVN (after some cleanup) but
because of these issues, I couldn't.

Yes, the current alignment code is not the most optimal and wastes some
memory, but at least it should work. Must be something trivial. Ideas,
opinions, suggestions welcomed.


More information about the fpc-devel mailing list