Dan Sugalski wrote:
looked. For this to be reasonable we need:
1) A stack chunk freelist, akin to the PMC and buffer freelists
Well, that did I write in my message. Please read it (again).
I did. The need for a freelist, however, has been there since the beginning. This isn't a new need--it was in my mail about this that started this round.
A freelist is a given here.
2) The stack entry has to look something like:
struct { struct IntStackFrame *prev; INTVAL Registers[REGSPERFRAME]; } IntStackFrame;
It could be a union of INTVAL, NUMVAL, STRING *, and PMC * if we don't want to maintain several free lists. Throwing a flag word in there's probably not out of order either.
This fixed size item doesn't really work IMHO. NUMVAL frames are of different size, as are user-stack entries.
User stack entries are different from backing stack frames. They need to be treated differently, and as such aren't under consideration here. I see that someone unified this all ages back--that was a mistake.
The indirection through the Buffer stuff has to go
Well in your last mail WRT that stuff you had PMCs there :)
Yeah, with no indirection. To be clear, I was proposing:
struct IntFramePMC {
pobj_t obj;
VTABLE *vtable;
struct PMC_EXT *pmc_ext;
DPOINTER *data;
PMC *_metadata;
struct _Sync *_synchronize;
PMC *_next_for_GC;
INTVAL Registers[REGISTERS_PER_FRAME];
};for an integer register frame, with pmc_ext set to &data, and data set to &Registers[0], and all the internal code skipping all the damn indirection and going directly to the register store frm the pointer to the frame.
For those folks following along that aren't familiar with what's here, this is equivalent to:
struct IntFramePMC {
struct PMC;
struct PMC_EXT;
INTVAL Registers[REGISTERS_PER_FRAME];
}which would be an OK way of doing it as well.
The Buffer stuff doesn't really hurt, when the chunks are coming directly from the free lists.
Yeah, it does. Besides the extra indirection, memory allocated with Parrot_allocate's movable by the GC. For fixed sized structures this is a waste, since there's no real reason to bother with compacting fixed-sized structures. Arenas with freelists work better there.
.. (Parrot_allocate really ought not ever be called for these fixed-sized structures, it's a huge waste)
They aren't fixed size--or only per stack kind, but with have more then one.
They're of fixed size. That there are multiple types doesn't change that. Every integer register frame will be the exact same size as every other one--they don't vary.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
