space profiling

[Henry Cejtin]

One  problem  (perhaps not a big deal) with statically allocating the bins is
that you have to know the number of allocation points.  Also if you are going
to  avoid  writing  out  0's  (which  will probably make the mlprof file much
smaller if you do) then you still have to scan the bin to see  the  size.   I
agree, the difference isn't much either way.

If the bins are statically allocated, then the code at an allocation point is
going to look like:

    save flags some where
    addl    <allocation size>, <low 32 bits of counter>
    adcl    $0, <high 32 bits of counter>
    restore flags from some where

If the bins are dynamically allocated, then the code at an  allocation  point
is going to be:

    movl    %esp, <save area>
    movl    <save area - 4>, %esp
    pushl   <allocation size>
    pushl   $<my bin address>
    jsr     <magic routine>

You  can't  store  the bin after the jsr because it is in code space which is
not writable.

And now the magic routine can do what ever  is  needed,  including  restoring
everything  (not  trivial  to  get the stack back and then do the return, but
doable).

Ok, I agree, the fixed bins is a win.

Did you agree or disagree that for timing the bins should still be 96 bits on
output?   I  think  they should just so that the code in mlprof doesn't worry
about more than one kind of bin.  Going to the sparse variety  will  probably
save more space than this will cost us.

CVS moves another slot higher on the magic list.