[fpc-devel] CMem allocator memory alignment experiment

[Marco van de Voort]

In our previous episode, Karoly Balogh (Charlie/SGR) said:
> 
> > > 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.

My point exactly. If tomorrow GCC 5 changes to 32-byte alignment on intel,
we are back to where we started.
 
> > 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.

So we provide multiple choices, and during problems people can fix their
issues by changing unit.

Administrating and releasing a holy default cmem in a target specific way is
IMHO a bridge too far, though maybe make an exception for targets like
x86_64 that really universally align to 16-byte.

Attempting t odo so only provides a temporarily relief from alignment issues
and triggers complaints from people that see their memory use increase
(alignment + pointer) without having a problem in the first place.
 
> > 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. :)

I assumed language helpers would access allocated size in Delphi. But then I can't
understand why your code then wouldn't work, since size is still directly
before allocation.
 
> (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.)

Not me. Last did that about 1.5 years ago just after 2.6.x to hunt fpdoc
bugs.