Dan Sugalski <[EMAIL PROTECTED]> wrote:
=item Interpreter pools will share allocation pools
All the interpreters in an interpreter pool will share header and memory allocation pools.
What about temporary PMCs (or strings)?
Those won't get marked as shared unless we're unconditionally marking things as shared. (Though we may just give 'em a mutex anyway)
Evaluating a non-trivial expression can have lot of these. Each new temp would need a lock on the memory sub-system.
Only on allocation. We could have a per-thread freelist if we wanted. Wouldn't be unreasonable.
Combined with the cost of:
=item All shared PMCs must have a threadsafe vtable
The first thing that any vtable function of a shared PMC must do is to aquire the mutex of the PMCs in its parameter list
i.e. typically 3 mutexes, it could be that the vtable of a shared PMC should just grab one interpreter lock (of the owner of that PMC) and that not all is shared (especially not the temps).
Yeah, but since PMCs aren't owned by any one interpreter in the pool but are rather pool-wide you run into either the global-lock problem (which kills performance on SMP systems) or interpreters potentially deadlocking on unrelated data access.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
