[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