I said:
> The FreeBSD malloc only opens a file if you have MALLOC_STATS defined
> and no where in the FreeBSD libc code is that defined. It's just
> like all the DEBUG things that NetBSD has. I think that is reasonable.

Oops, that isn't correct. It still tries to read a config file. Sorry,
you were right!

I put the FreeBSD malloc in gomoku and look at how it handles the memory:

(some random samples)

root     16895 97.5 33.9  8992 8776 p0  R+    5:43PM    1:20.33 ./gomoku -c
root     16895 94.6 35.0  9288 9072 p0  R+    5:43PM    1:24.19 ./gomoku -c
root     16895 96.5 40.7 10768 10552 p0  R+    5:43PM    1:44.10 ./gomoku -c
root     16895 93.7 41.9 11080 10864 p0  R+    5:43PM    1:47.07 ./gomoku -c
root     16895 93.5 43.8 11584 11368 p0  R+    5:43PM    1:55.55 ./gomoku -c
root     16895 92.9 44.7 11808 11600 p0  R+    5:43PM    2:03.08 ./gomoku -c
root     16895 95.0 28.7  7656 7448 p0  R+    5:43PM    2:19.51 ./gomoku -c
root     16895 93.0 33.1  8776 8568 p0  R+    5:43PM    2:24.18 ./gomoku -c
root     16895 91.1 35.3  9360 9152 p0  R+    5:43PM    2:27.39 ./gomoku -c
root     16895 84.6 37.5  9936 9728 p0  R+    5:43PM    2:31.95 ./gomoku -c
root     16895 81.8 39.2 10360 10152 p0  R+    5:43PM    2:35.36 ./gomoku -c
root     16895 76.2 54.7 14400 14192 p0  R+    5:43PM    3:43.68 ./gomoku -c
root     16895 76.2 54.7 14400 14192 p0  R+    5:43PM    3:45.30 ./gomoku -c
root     16895 75.1 18.3  4952 4744 p0  R+    5:43PM    3:46.88 ./gomoku -c
root     16895 77.5 20.5  5520 5312 p0  R+    5:43PM    3:50.75 ./gomoku -c
root     16895 82.2 23.6  6320 6112 p0  R+    5:43PM    3:58.40 ./gomoku -c
root     16895 81.3 23.8  6368 6160 p0  R+    5:43PM    4:00.70 ./gomoku -c
root     16895 79.7 18.3  4952 4744 p0  R+    5:43PM    4:02.11 ./gomoku -c
root     16895 99.0 31.4  8344 8136 p0  R+    5:43PM    7:03.34 ./gomoku -c
root     16895 95.8 31.5  8384 8176 p0  R+    5:43PM    7:05.29 ./gomoku -c
root     16895 93.0 32.7  8680 8472 p0  R+    5:43PM    7:07.15 ./gomoku -c
root     16895 99.0 40.6 10744 10536 p0  R+    5:43PM   10:56.82 ./gomoku -c
root     16895 83.6 67.5 21040 17504 p0  R+    5:43PM   15:03.47 ./gomoku -c
root     16895 82.4 67.6 21056 17544 p0  R+    5:43PM   15:05.70 ./gomoku -c
root     16895 82.0 71.2 22024 18480 p0  R+    5:43PM   15:57.54 ./gomoku -c
root     16895 83.1 17.9  6864 4624 p0  R+    5:43PM   16:33.00 ./gomoku -c

Each time the memory usage drops back, it has just chosen a location.

There are few 64 bit issues with the malloc code, mostly to do with the
use of unsigned integer #defined values. An extra 'L' allows the code to
work on NetBSD/Alpha. FreeBSD also has an extra option to madvise()
to free up pages. That is one of the options that the config file
can give. The options can also come from an environment variable.

So, on my system, gomoku is unusable with NetBSD's malloc, but works
well with FreeBSD's malloc (even with all the extra sanity checking
enabled). Food for thought.

PS. gomoku still wins _every_ time. Amazing!

-- 
John Birrell                                CIMlogic Pty Ltd
jb@cimlogic.com.au; jb@netbsd.org           119 Cecil Street
Ph  +61  3 9690 6900                        South Melbourne Vic 3205
Fax +61  3 9690 6650                        Australia
Mob +61 18  353  137