![](https://secure.gravatar.com/avatar/d360ec751eb90bc963c5b03544d88cf5.jpg?s=120&d=mm&r=g)
On Tue, Jul 21, 2009 at 2:23 PM, Erik Huelsmann<ehuels@gmail.com> wrote:
How many frames will then hang around? If I make a deep call, and never do another deep call, will I then have frames lurking around from the deep call? In the current implementation: yes. However, with this improvement, there's probably some room for keeping a very small statistic of some kind which would allow building a shorter list of stack frames (ie dispose of all / a few). Ofcourse, that would undo some of the performance gain. Do you have ideas? I thought to use a weak reference, meaning GC will
collect the memory if it needs it, but other than that, I certainly think setting an upperbound won't fix the "keep hanging around" issue.
I don't have a detailed implementation idea in mind, but on the general level, the stack-frame cache should be 1) per-thread (in order to avoid synchronisation overhead) 2) chunked-allocated (set aside a bunch, when all are unwound, remove a chunk, before that, mark them unused for re-use) I don't yet know what would be a proper data structure for 2).