|
From: <sv...@va...> - 2005-12-16 16:10:42
|
Author: njn
Date: 2005-12-16 16:10:34 +0000 (Fri, 16 Dec 2005)
New Revision: 5359
Log:
Make BYTES_PER_SEC_VBIT_NODE less 32-bit specific.
Modified:
branches/COMPVBITS/memcheck/mc_main.c
Modified: branches/COMPVBITS/memcheck/mc_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/mc_main.c 2005-12-16 01:08:22 UTC (rev 53=
58)
+++ branches/COMPVBITS/memcheck/mc_main.c 2005-12-16 16:10:34 UTC (rev 53=
59)
@@ -469,13 +469,13 @@
static ULong sec_vbits_bytes_curr =3D 0;
static ULong sec_vbits_bytes_peak =3D 0;
=20
-// 4 is the best value here. We can go from 1 to 4 for free -- it doesn=
't
-// change the size of the SecVBitNode because of padding. If we make it
-// larger, we have bigger nodes, but can possibly fit more partially def=
ined
-// bytes in each node. In practice it seems that partially defined byte=
s
-// are not clustered close to each other, so going bigger than 4 does no=
t
-// save space.
-#define BYTES_PER_SEC_VBIT_NODE 4
+// sizeof(Addr) is the best value here. We can go from 1 to sizeof(Addr=
)
+// for free -- it doesn't change the size of the SecVBitNode because of
+// padding. If we make it larger, we have bigger nodes, but can possibl=
y
+// fit more partially defined bytes in each node. In practice it seems =
that
+// partially defined bytes are rarely clustered close to each other, so
+// going bigger than sizeof(Addr) does not save space.
+#define BYTES_PER_SEC_VBIT_NODE sizeof(Addr)
=20
typedef=20
struct {
|