Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote: Hi Liz,
> Please note that these are comments from a Parrot list lurker and > outsider, but also as someone with some hands on experience with Perl > threads... ;-) And probably stating the bleedingly obvious. I'm appreciating your (and of course other) comments very much, the more that my experience with the topic and all related issues is very limited. > At 11:09 +0100 12/21/03, Leopold Toetsch wrote: >> *If* ParrotClasses are per thread (very likely yes - different >>threads might create different objects of different classes >>dynamically) *and if* Parrot_class_register() creates entries in >>Parrot_base_vtables[], then this structure has to be per interpreter >>too. > I agree. > Ideally I'd see a COWed structure: a thread startup would not > actually copy the main vtable structure. As soon as something needs > to be specific for the thread, only then needs that structure to be > copied for the thread (and possibly only that part that is actually > different from the thread a thread is inheriting from. Sounds reasoanble, yes. Given, that we go for the dynamic case cited above, I can imagine that we finally have: 1) a real global Parrot_base_vtables[] containing pointers to the local *static* temp_base_vtable inside the PMC classes C file. 2) another per interpreter vtable array holding all dynamic entries Access to the former is per index like now, for the latter, the index has to be obtained once at tuntime per name lookup. 1) is for all static classes: PMCs inside parrot and ParrotClasses loaded into the first interpreter from the PBCs metadata. And: 3) a separate array for the JITed method stubs, which are per interpeter and only if the platform can generate such stubs on the fly. > The main problem with Perl 5 ithreads is the thread startup CPU and > memory usage. It's what makes Perl 5 ithreads _very_ hard to use in > a production environment. That overhead needs to be prevented at all > costs in Parrot. That are additional issues, which I'll address later. There are no shared PMCs yet in Parrot. But what I currently know is: a single threaded parrot which can handle huge PMC amounts fast, should use huge arena memory pools, and worse (when ARENA_DOD_FLAGS is on) fixed sized pools[1]. This doesn't cooperate with a heavily multi-threaded usage, where each thread doesn't deal with a lot of data. [1] I already have some ideas, to use variable sized pools though ... > Hope this made sense. Very much, thank you, yes. > Liz leo
