On 10/3/05, Robin Garner <[EMAIL PROTECTED]> wrote: > Florian Weimer wrote: > > The conclusion reached in the OOPSLA paper referred to (Choi et al 1999) > is that stack allocation produced a relatively insignificant speedup, > but that locking optimizations for objects that don't escape thread > context was significant. > > In a heap with a bump-pointer allocator, allocation is cheap. Stack > allocation can potentially produce a slow-down by reducing locality in > the stack, and complicating the task of scanning the stack. >
Another problem with stack allocation is that it increases object lifetimes because you cannot reclaim the storage until the stack frame disappears. It is possible to work around this if your escape analysis is sophisticated enough. Synchronization overhead definitely improves, but synchronization was so slow for such a long time that many mature programs already eliminate the synchronization by hand (consider ArrayList vs. Vector). Doing escape analysis in a JIT is not difficult; see, for example, my OOPSLA'01 paper or Suganuma et al PLDI'03. The real performance benefit of escape analysis is when you can do scalar replacement, replacing each of the object's fields/array elements with a register. Thus, you eliminate the object entirely, and making its fields into registers allows many more optimizations. John Whaley
