Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote: > Ideally I'd see a COWed structure: a thread startup would notactually 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.
I'm not sure the per interpreter vtable array should exist at all until it is needed. One of the things people use threads for, is to have many, many worker threads doing the same thing. The way to do this would be to start 1 thread that sets up all of the specific worker related changes to the global environment, which would set up the per interpreter vtable array. Then all threads started from that thread would use exactly _that_ structure (without any copying or cloning or anything). That is, if I'm understanding what vtables do correctly.
Not copying anything is what threaded applications in general make such a good thing (and copying everything for each thread is currently what makes Perl 5 ithreads such a badly performing threads implementation).
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.
Indeed.
I'm someone who started in the PC-DOS world, migrated to *nix about 10 years ago and started with Perl threads about 1.5. years ago. I know a lot of how _not_ to do threads. Maybe someone with more experience on inherently threaded systems, suchas Win32 and OS/2 should speak up.
Liz
