tree bc60831ea1482a2576646558b33ee932f8d8043c
parent 238a3c31e3bb21cfd5790f1353603a2884cb0968
author nethercote <nethercote@a5019735-40e9-0310-863c-91ae7b9d1cf9> 1092217252 +0000
committer nethercote <nethercote@a5019735-40e9-0310-863c-91ae7b9d1cf9> 1092217252 +0000


Big overhaul of the allocator.  Much of the structure is the same, but
lots of the details changed.  Made the following generalisations:

- Recast everything to be entirely terms of bytes, instead of a mixture
  of (32-bit) words and bytes.  This is a bit easier to understand, and
  made the following generalisations possible...

- Almost 64-bit clean;  no longer assuming 32-bit words/pointers.  Only
  (I think) non-64-bit clean part is that VG_(malloc)() et al take an
  Int as the size arg, and size_t is 64-bits on 64-bit machines.

- Made the alignment of blocks returned by malloc() et al completely
  controlled by a single value, VG_MIN_MALLOC_SZB.  (Previously there
  were various magic numbers and assumptions about block alignment
  scattered throughout.) I tested this, all the regression tests pass
  with VG_MIN_MALLOC_SZB of 4, 8, 16, 32, 64.  One thing required for
  this was to make redzones elastic;  the asked-for redzone size is now
  the minimum size;  it will use bigger ones if necessary to get the
  required alignment.

Some other specific changes:

- Made use of types a bit more;  ie. actually using the type 'Block',
  rather than just having everything as arrays of words, so that should
  be a bit safer.

- Removed the a->rz_check field, which was redundant wrt. a->clientmem.

- Fixed up the decision about which list to use so the 4 lists which
  weren't ever being used now are -- the problem was that this hasn't
  been properly updated when alignment changed from 4 to 8 bytes.

- Added a regression test for memalign() and posix_memalign().
  memalign() was aborting if passed a bad alignment argument.

- Added some high-level comments in various places, explaining how the
  damn thing works.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2579 a5019735-40e9-0310-863c-91ae7b9d1cf9