Changes resulting from porting to AIX5:
- Auxiliary primary map handling has been redone, so that the
performance penalty for hitting memory above the magic 32G limit is
much reduced, and also the number of usable maps is limited only by
how much memory is available. The current code has been tested on
64-bit AIX for processes up to about 8GB in size.
The auxiliary primary maps are now stored in an OSet, "auxmap_L2".
However, looking up in an OSet for each memory reference is
expensive. So the OSet is 'fronted' by 24-entry array which holds
pointers to the 24 most recently used auxiliary primary maps.
Accesses to this array are made faster by incrementally rearranging
it on every lookup (if the requested map is found in the array, it
is moved one element closer to the start of the array).
Logically speaking, auxmap_L1 is a cache of auxmap_L2. The L2-L1
relationship is one of inclusion; iow L2 is not a victim cache.
There is extensive new sanity check code for these structures.
- Along with the auxmap changes are semi-fast cases in mc_LOADVn_slow
and mc_STOREVn_slow. These catch naturally aligned, word-size loads
which fall into addressible memory, and handle them directly rather
than in a byte-by-byte fashion.
- Fix longstanding error with alignment checks in
{new,die}_mem_stack_N. Previously, these checked the alignment of
the new SP value without taking the stack redzone size into account.
This is only safe if the redzone size is 8-aligned. The right thing
to do is check alignment after adding on the redzone size.
- Add a new mechanism which allows specification, on the command line,
of address ranges which memcheck is to 'ignore'. Meaning that it
regards all writes to those ranges as acceptable and all reads from
those ranges as acceptable and returning initialised data. This is
done without disturbing the existing finally-balanced bitmap
machinery. Instead, in mc_record_address_error, just ignore the
error if the address falls inside an ignored-range.
There is a new command-line flag --ignore-ranges= to specify
the address ranges. Currently up to 4 non-overlapping ranges may
be specified.
This kind of thing is useful if you want to do some strange thing
like map a high-performance network card into memory and can't be
bothered to tell memcheck about it through the official channels
(intercepting syscalls/ioctls and telling aspacem about them.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6256
Supply our own random number generator; else this test produces different
results on different platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6253
Makefile.am changes for AIX5. Almost all boilerplate stuff fitting in
with the existing factorisation scheme. The only change of interest
is that configure.in now generates automake symbols of name
VGP_platform and VGO_os, whereas previously it just made VG_platform
which was a bit inconsistent with the VGP/VGO/VGA scheme used in C
code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6242
interface, except for the syscall numbers, into that. Mostly this
means moving include/vki-*.h to include/vki/vki-*.h.
include/pub_tool_basics.h previously dragged in the entire kernel
interface. I've done away with that, so that modules which need to
see the kernel interface now have to include pub_{core,tool}_vki.h
explicitly. This is why there are many modified .c files -- they have
all acquired an extra #include line.
This certainly breaks all platforms except x86. Will fix shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6225
Here's an update to the mempool move / change client requests and sanity
checking. The following changes are present:
- Added one more (hopefully last) client request, a predicate to
test whether a mempool anchor address is currently tracked.
It turns out mozilla's arena-using code is sufficiently inconsistent
in its assumptions that it's very difficult to phrase the valgrind
client-request annotations without this request. Namely: sometime
arena-init and arena-free operations are assumed to be idempotent.
- Fixed a very rapid tool-memory leak in the mempool sanity check
routine. The previous version of the patch I posted would use all
memory even on my Very Beefy Test Machine within ~15 minutes of
browsing with firefox.
- Added a little logging code to print the counts of pools and chunks
active every ~10000 sanity checks, when running with -v.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6197
they had size one. Otherwise they appear to cover no address space,
so no pointers to them are ever found, and so they are always
incorrectly marked as leaked.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5994
40% speedup on artificial programs which just do realloc() and nothing
else, and about a 3-4% speedup on starting kpresenter-1.5.0 and
loading a 16-slide presentation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5880
use an mmx register (which is the same thing in disguise) since mmx
loads/stores are guaranteed to be the identity. This should fix
failures of this test on x86-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5843
stores of char/short/int/int64/double at random offsets and hence
alignments in an array. It does it in a way in which the computation
just computes the expected V bits, and hence can check whether these
seem correct.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5811
