[fpc-devel] CMem allocator memory alignment experiment
Marco van de Voort
marcov at stack.nl
Wed Nov 19 13:15:17 CET 2014
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
> (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
More information about the fpc-devel