Dan Sugalski <[EMAIL PROTECTED]> wrote: [ stack layout ]
>>I'd rather not have the store statically inside the hunk: >>- small objects code currently has an upper limit for sized header pools > Doesn't mean we have to use them, honestly. A separate arena for them > is fine. Each sized item (a Buffer_like header of one size class) has its own arena. This isn't the problem. But the more different arenas we have, the more we have to walk during DOD. >>- more and differently sized pools impose negative effects on DOD times > While true, we're already walking the stack frame areas, so I'm not > sure it'll work out that way. Yes. But only one arena. With the register frames in place, we would have at least 2 more arenas with (1024+x) and (2048+x) bytes for x=12 currently (32-bit systems). And the question is: should we unify other stacks (Pad, User, Control) with the register frame stacks? stacks.c's implementation has additionally a stack->next pointer which keeps a spare junk against thrashing and it has a stack->limit to guard against wild running user code. leo
