On Tue, Nov 5, 2013 at 8:00 AM, Ben Kloosterman <[email protected]> wrote:
> On Tue, Nov 5, 2013 at 10:16 PM, Jonathan S. Shapiro <[email protected]>wrote: > > >> The Go story seems kind of weird. Their description of hot stacks makes >> it sound like they were allocating and releasing too aggressively. I also >> think the "just double the stack size" heuristic in the new scheme is >> flawed, but they'll figure that out shortly. >> > > Maybe they wont , I though double was not aggressive enough and its too > aggresive for large stacks.. > Yup. The right strategy is to start with something reasonable, use doubling up to some limit, and then use a known growth factor for further expansion. i was kind of shocked they still had all those stack checks in every method > ( because thats what LLVM does) . If you don't use a guard page, you kinda have to do the stack checks. There several two possible reasons *not* to use a guard page: 1. You are executing in a non-paged environment 2. You really think that virtual address space is at a premium 3. You think that large-page TLBs matter But the way to think about this is that frame allocation on the stack is just bump allocation. The real issue with stack segmentation is the fact that the bump allocation will repeatedly take the long path at the stack segment boundary unless you are prepared to grow the stack. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
