Stack vs. heap allocated execution frames

["Guillermo J. Rozas" <gjr@martigny.ai.mit.edu>]

To the list that Marc specified (he beat me to it), other factors can
be added.  To my knowledge _all_ of them are architecture and/or
implementation specific, so it may be possible to design a combination
of architecture and implementation that does not incur in them.
However, the prospects for that are not too great at the moment.

Among the unlisted factors:

- Extra stores for GC headers for heap-allocated frames.

- Inability/difficulty to use stack-optimization hardware on some
  architectures (e.g. register windows on Sparc).

- TLB effects (eating up more address space).

- Cache effects (I know about the DEC 5000 paper, but very few caches
  are this way, and future trends work against them).

- The relative cost of loading vs. addition keeps increasing, hence
  having a loaded "frame pointer" vs. a directly calculated "frame
  pointer" can slow access to the frame after a return by several
  cycles.

I will admit, however, that in many cases these effects are small, but
neither zero, nor negligible in important cases.