here we have a slightly buggy hash table implementation.
- passes all it's tests.  may even have been used successfully
  in several small projects, each creating a small number of hash
  tables - eg one!
- about to embed it into a much bigger system, that will create,
  populate, copy and destroy hash tables thousands of times
- let's test that!
- new test program <<iterate N M>> that performs all previous tests
  repeatedly: N times, sleeping M seconds afterwards.
- Behaviour should be linear with N.  Test it:
- use time ./iterate N 0 for one data point
- use ./testme shell script to try several values of N
- graph the results in your head, or explicitly (gnuplot etc)
- Find dramatic non-linear behaviour around 6-8k
  iterations on an older lab machine (eg a corona or a ray):
- Twice as slow, CPU %age falls [was previously 100% cpu bound
  up to then, bizarrely the process starts doing I/O]
- What's happening?
- Try monitoring with top, configured to update
  every minute (d 1), sort by %age of memory (O n).
  Write this config out (W).
- Run iterate with a time delay:
   time ./iterate 8000 10
- and watch top!
- you'll see that:
  - iterate's memory grows continuously to larger than the
    machine's physical memory,
  - tops out at about 80% of physical memory, the system
    won't let it have more,
  - the system starts swapping (%wait goes busy),
  - machine goes very slow!  high load average
  - all processes slow, not just iterate!

- debug this via libmem, either do it here (I suggest
  running the simpler testhash program when instrumented
  with libmem), or in the pre-prepared 07.hash-membug-withmem
- details in there
