|
From: Nicholas N. <nj...@ca...> - 2004-07-25 12:19:37
|
Hi, I've started looking at an Opteron port. In making the code 64-bit clean, one big area that needs fixing is the allocator, vg_malloc2.c. I've completely reworked it so that it's (almost) 64-bit clean. The diff is at www.cl.cam.ac.uk/~njn25/diff.64-bit-alloc The new version of vg_malloc2.c is at www.cl.cam.ac.uk/~njn25/vg_malloc2.c Reading the diff is hard because so much has changed in vg_malloc2.c. The change log is below. I'd be interested in hearing feedback. I'd like to see the changes go in now, even though Opteron support is still a long way off. I think I improved enough things while doing the change for it to be worthwhile (eg. I find it easier to understand, there are more comments, some incorrect corner cases are now working, magic numbers have been removed), and it would be good to have it in earlier to flush out any problems that would affect x86 (32-bit machines) sooner rather than later. Opinions? Thanks. N 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 a->rz_check, which was redundant wrt. a->clientmem. - Removed VG_(is_inside_segment_mmapd_by_low_level_MM)(), which was not being used. - 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. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-09 12:40:11
|
On Sun, 25 Jul 2004, Nicholas Nethercote wrote: > In making the code 64-bit clean, one big area that needs fixing is the > allocator, vg_malloc2.c. I've completely reworked it so that it's > (almost) 64-bit clean. > > The diff is at > > www.cl.cam.ac.uk/~njn25/diff.64-bit-alloc > > The new version of vg_malloc2.c is at > > www.cl.cam.ac.uk/~njn25/vg_malloc2.c > > Reading the diff is hard because so much has changed in vg_malloc2.c. > The change log is below. > > I'd be interested in hearing feedback. I'd like to see the changes go in > now, even though Opteron support is still a long way off. I think I improved > enough things while doing the change for it to be worthwhile (eg. I find it > easier to understand, there are more comments, some incorrect corner cases > are now working, magic numbers have been removed), and it would be good to > have it in earlier to flush out any problems that would affect x86 (32-bit > machines) sooner rather than later. Opinions? I'll commit this in the next day or so if no-one objects. N |