Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 5:16 PM +0100 1/20/04, Leopold Toetsch wrote: >>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) This needs either one check per PMC, if its shared or not, or additional costs for locking temps. Both is rather expensive, compared to the raw working functionality of a vtable. >> 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. Yes: "Each *new* temp .." > ... We could have a per-thread freelist if we wanted. > Wouldn't be unreasonable. That already smells like separate memory sub-systems. The freelist has to be filled first. During DOD runs, it has to be refilled. To achieve some locality of the temp PMCs, you can't just give these to arbitrary intpreters. Separate free lists seem also to imply separate DOD runs to cleanup the temps. >>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 the owner is for me the interpreter, that did allocate the arena. > ... 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. Could be. But the performance is the overall throughput. When a lot of fine grained locks (plus memory subsystem locks for temps) take much longer then one global lock, then that scheme can nethertheless be slower on SMP machines. It would scale better though for more CPUs. Deadlocks shouldn't be a problem, if exactly one vtable (like in SharedRef) just grabs one and only one lock. leo
