ftmemsim-valgrind/include/pub_tool_poolalloc.h
Philippe Waroquiers 435d51c1c9 This patch reduces the memory needed for the linesF.
Currently, each SecMap has an array of linesF, referenced by the linesZ
of the secmap that needs a lineF, via an index stored in dict[1].
When the array is full, its size is doubled.
The linesF array of a secmap is freed when the SecMap is GC-ed.
The above strategy has the following consequences:
  A. in average, 25% of the LinesF are unused.
  B. if a SecMap has 'temporarily' a need for linesF, but afterwards,
     these linesF are converted to normal lineZ representation, the linesF
     will not be recuperated unless the SecMap is GC-ed (i.e. fully marked
     no access).

The patch replaces the linesF array private per SecMap
by a pool allocator of LinesF shared between all SecMap.
A lineZ that needs a lineF will directly point to its lineF (using a pointer
stored in dict[1]), instead of having in dict[1] the index in the SecMap
linesF array.
When a lineZ needs a lineF, it is allocated from the pool allocator.
When a lineZ does not need anymore a lineF, it is returned back to the
pool allocator.

On a firefox startup, the above strategy reduces the memory for linesF
by about 42Mb. It seems that the more firefox is used (e.g. to visit
a few websites), the bigger the memory gain.
After opening the home page of valgrind, wikipedia and google, the memory
gain is about 94Mb:
trunk:
  linesF:    392,181 allocd ( 203,934,120 bytes occupied) (   173,279 used)
patch:
  linesF:    212,966 allocd ( 109,038,592 bytes occupied) (   170,252 used)

There is also less alloc/free operations in core arena with the patch:
trunk:
  core    :   810,680,320/  802,291,712 max/curr mmap'd, 17/19 unsplit/split sb unmmap'd,    759,441,224/  703,191,896 max/curr,    40631760/16376828248 totalloc-blocks/bytes,   188015696 searches 8 rzB
patch:
  core    :   701,628,416/  690,753,536 max/curr mmap'd, 12/29 unsplit/split sb unmmap'd,    643,041,944/  577,793,712 max/curr,    32050040/14056017712 totalloc-blocks/bytes,   174097728 searches 8 rzB


In terms of performance, no CPU impact detected on Firefox startup.
Note we have no representative reproducible (and preferrably small)
perf test that uses extensively linesF. Firefox is a good heavy lineF
user but is far to be reproducible, and is very far to be small.

Theoretically, in terms of CPU performance, the patch might have some
small benefits here and there for read operations, as the lineF pointer
is directly retrieved from the lineZ, rather than retrieved via an indirection
in the linesF array.
For write operations, the patch might need a little bit more CPU,
as we replace an
  assignment to lineF inUse boolean to False (and then probably back to True
  when the cacheline is written back)
by 
  a call to pool allocator VG_(freeEltPA) (and then probably a call to
  VG_(allocEltPA) when the cacheline is written back).
These PA functions are small, so cost should be ok.
We might however still maintain in clear_LineF_of_Z the last cleared lineF
and re-use it in alloc_LineF_for_Z. Not sure how many calls to the PA functions
would be avoided by this '1 elt cache' (and the needed 'if elt == NULL'
check in both clear_LineF_of_Z and alloc_LineF_for_Z.
This possible optimisationwill be looked at later.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15253
2015-05-17 19:32:42 +00:00

102 lines
4.2 KiB
C

/*--------------------------------------------------------------------*/
/*--- A simple pool (memory) allocator. pub_tool_poolalloc.h ---*/
/*--------------------------------------------------------------------*/
/*
This file is part of Valgrind, a dynamic binary instrumentation
framework.
Copyright (C) 2011-2013 OpenWorks LLP info@open-works.co.uk,
Philippe Waroquiers philippe.waroquiers@skynet.be
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307, USA.
The GNU General Public License is contained in the file COPYING.
*/
#ifndef __PUB_TOOL_POOLALLOC_H
#define __PUB_TOOL_POOLALLOC_H
#include "pub_tool_basics.h" // UWord
//--------------------------------------------------------------------
// PURPOSE: Provides efficient allocation and free of elements of
// the same size.
// This pool allocator manages elements alloc/free by allocating
// "pools" of many elements from a lower level allocator (typically
// pub_tool_mallocfree.h).
// Single elements can then be allocated and released from these pools.
// A pool allocator is faster and has less memory overhead than
// calling directly pub_tool_mallocfree.h
// Note: the pools of elements are not freed, even if all the
// single elements have been freed. The only way to free the underlying
// pools of elements is to delete the pool allocator.
//--------------------------------------------------------------------
typedef struct _PoolAlloc PoolAlloc;
/* Create new PoolAlloc, using given allocation and free function, and
for elements of the specified size. alloc_fn must not return NULL (that
is, if it returns it must have succeeded.)
This function never returns NULL. */
extern PoolAlloc* VG_(newPA) ( UWord elemSzB,
UWord nPerPool,
void* (*alloc)(const HChar*, SizeT),
const HChar* cc,
void (*free_fn)(void*) );
/* Free all memory associated with a PoolAlloc. */
extern void VG_(deletePA) ( PoolAlloc* pa);
/* Allocates an element from pa. The function never returns NULL. */
extern void* VG_(allocEltPA) ( PoolAlloc* pa);
/* Free element of pa. */
extern void VG_(freeEltPA) ( PoolAlloc* pa, void* p);
/* A pool allocator can be shared between multiple data structures.
For example, multiple OSet* can allocate/free nodes from the same
pool allocator.
The Pool Allocator provides support to use a ref counter
to detect a pool allocator is not needed anymore.
It is the caller responsibility to call VG_(addRefPA) for
each new reference to a pool and VG_(releasePA) when such a reference
disappears.
VG_(releasePA) will automatically call VG_(deletePA)
to delete the PA when the ref counter drops to 0. */
// VG_(addRefPA) indicates there is a new reference to pa.
extern void VG_(addRefPA) ( PoolAlloc* pa);
// VG_(releasePA) decrements the pa reference count and deletes the pa if that
// reference count has dropped to zero. Returns the new value of the reference
// count.
extern UWord VG_(releasePA) ( PoolAlloc* pa);
// How many elements are managed by the pool 'pa'. This includes
// the elements allocated by VG_(allocEltPA), the elements freed by
// VG_(freeEltPA) and the elements that are in a block and have not
// yet been allocated.
extern UWord VG_(sizePA) ( PoolAlloc* pa);
#endif // __PUB_TOOL_POOLALLOC_
/*--------------------------------------------------------------------*/
/*--- end pub_tool_poolalloc.h ---*/
/*--------------------------------------------------------------------*/