lies, damn lies and erlang memory use

[Matthias Lang]

Hi,

I seem to be having my annual horror trip with memory
management. Maybe someone has some clues. I'm using R8B-2, cross
compiled for a PPC running linux.

The underlying problem is that the Erlang VM appears to grow, slowly,
without apparent bound. As always, I have no idea why.

If I run the instrumented VM on it, it seems to show me rather more
holes than I expected:

  27 20 32 20 158 30 2222 6078 26 20 35 22 60 2222 30 30 3902 30 32 28
  24 24 20 1694 20 24 24 24 24 24 24 32 24 24 20 24 20 20 20 20 20 20 24
  24 24 20 24 24 24 20 32 35 24 24 24 24 24 24 24 24 24 24 24 24 24 24
  [many lines omitted]
  6982 2222 5598 30 17280 20094 33734 22 6678 5438 27726 23022 4734 1878
  2222 12622 30 712 856 3790 2222 12926 20702 30 32 5636 27262 60878
  30910 3790 11302

Adding them up, I get more than 6M of holes, which seems a little rich
given that instrument:limits reports 11M in total.

Is this normal, or is something strange going on? 

(Yes, you detect my tone of doubt, which is provoked by there being
many different BIFs and things for reporting on Erlang memory use, but
it's not very obvious which ones refer to what. They also seem to lie
quite a bit, for instance:

  - c:memory(). 

      Looks suspect; it's "total" is always much less than
      the sum of the parts it reports, e.g. on x86 linux:

      Eshell V5.1.2  (abort with ^G)
      1> c:memory().
      [{total,2109082},
      {processes,181236},
      {system,1927846},
      {atom,180221},
      {atom_used,150362},
      {binary,96064},
      {code,1156376},
      {ets,72948}]

  - erlang:system_info(allocated_areas)

      This is where c:memory() appears to get most of its information
      from, and it looks more promising. The values add up to about
      20% less than what the OS says and the gulf tends to widen as
      more memory is used.

)

Clues appreciated! Anyone have good or bad experiences with
disabling sl_alloc and using plain old malloc instead?

Matthias