[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: 

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/ )


More information about the fpc-devel mailing list