[fpc-devel] Need heap manager -gv explanation
Jonas Maebe
jonas.maebe at elis.ugent.be
Tue Apr 29 11:00:44 CEST 2014
On 29/04/14 08:45, Sergei Gorelkin wrote:
> -gv switch in command line disables the optimized i386 Move procedure
> (and that's basically the only thing it does), so it indeed should cause
> slowdown. Comments say that valgrind (some pretty old version of it) is
> unable to handle the optimizied Move code. In the meantime, valgrind was
> presumably fixed. At least since my involvement with FPC back in 2005 I
> was able to use valgrind to profile programs without any trouble, and
> without recompiling them with -gv.
> So maybe it's time reconsider the action of -gv switch, or to remove it
> altogether.
As Tomas mentioned, -gv also causes the use of the C memory manager.
This is required because while Valgrind also recognises mmap (as used by
our memory manager), the result is not fine grained enough to be of any
use: Valgrind can't magically determine that our heap manager divides
the mmap'ed blocks into smaller allocations.
Regarding the SSE support in Valgrind: its assembler and disassembler
have supported those instructions since a long time, but memcheck
didn't. In particular, it didn't support memory initialisations using
the movaps instruction. And at least in 2010, it still didn't:
https://code.google.com/p/nativeclient/issues/detail?id=2251
Maybe it's finally fixed in the latest Valgrind release (from October
last year), as the changelog lists various SSE fixes for optimized
string copy routines (search for "SSE" in https://lwn.net/Articles/572790/ )
Jonas
More information about the fpc-devel
mailing list