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.
True enough, and it likely means that we end up with the size as a variable rather than an embedded constant which slows things down a bit, which isn't good.
>>- 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.
Unifying the user and control stacks make sense. I don't see any point in unifying the pad stack with anything, since it's not really a stack as such, or at least ought not be, and it's got a more complex linking structure anyway.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
