[fpc-devel] CMem allocator memory alignment experiment

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 19 Nov 2014, Marco van de Voort wrote:

> > Since the RTL's allocator is documented to align to 16 bytes, it's
> > definitely an issue also with Pascal code. We do have code where also
> > Pascal side triggers the aligment issue, but indeed, the main issue is
> > with linked C libs, depending on pointers from the Pascal side.
>
> I'm not an alignment expert, but only when loading types that are larger
> than the pointer size, since only those are not naturally aligned and so
> could cross cacheline bounderies?

Yes, but the problem is, you have no idea what the underlying library
does, and GCC seems to compile code where it thinks it would be more
optimal which expects the malloc()-alike alignment at least.

> Anyway, I don't see a problem with having a cmemalign16 (or -32 or whatever)
> unit, but I wouldn't blow up allocation unnecessary if there hasn't been a
> real problem in most cases.

Well, I would still fix the original cmem to not destroy the underlying
malloc alignment, but that patch should be much less invasive. Another
idea would be to add a simple helper to the RTL, to allocate/free an
aligned memory block, something libc already has, IIRC.

> Since cmem is documented to be used from the main program file (iow the
> users code), that would nicely put the responsibility there.

Yes, but this still doesn't answer the question why my cmem16 doesn't work
for complex apps, while it seems to pass all simple heap testcases. :)

(On a slightly related note, did anyone run current trunk compiler with
cmem allocator through valgrind recently? I seem to get quite some "using
uninitialized memory" hits.)

Charlie