Karoly Balogh (Charlie/SGR) wrote:
Hi,
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.
Since cmem is intended for use by FPC, I don't see this as a serious
issue unless somebody is exchanging malloc()ed blocks between Pascal and
C code. However I'm not saying that it's not worth fixing.
This causes multiple performance and other issues, especially on
processors which require stricter alignment (most ARM CPUs, but also x86
with SSE, etc).
I'm not sure to what extent this remains an issue with current ARM
chips. I've got limited ARM hardware, but some tests that I did with
somebody else a few months ago didn't show up any issues.
It's more of a problem with SPARC particularly on Linux, but that's
rapidly going down the tubes as a viable platform- in part because this
very issue breaks a lot of stuff and maintainers have neither hardware
nor incentive to investigate.
Perhaps the most serious scenario is where an architecture or particular
implementation requires alignment, but the kernel traps alignment errors
and fixes them silently. SPARC Solaris does this and my understanding is
that it introduces a very significant performance overhead; ARM Linux
may also do it (where demanded by the hardware) but my understanding is
that notifications can be enabled.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
