Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> At 14:16 -0500 12/22/03, Dan Sugalski wrote:
>>Yes. Making a PMC shared can be as simple as swapping out the vtable
>>pointer in the PMC structure--no need to move it around at all. (Or,
>>worst case, turning the PMC into a reference PMC for the actual PMC,
>>whose contents get moved to a new header, which is legal-ish)
> It's that last thing I'm worried about. That all thread related
> things in Parrot are forced to use an extra indirection and
> consequent performance penalty.
I'm thinking of:
1) PMC class definitions get an extra flags entry (or two):
- shared_only (e.g. msg-PMC for inter-thread communication)
- shared_too (PMC has a shared variant)
If these flags are seen, the PMC compiler generates the vtable
methods like now done already for the Const$PMCs.
That is, we have e.g. a SharedPerlUndef PMC at compile time.
2) the Perl5ish declaration
my $var : shared;
is basically:
$P0 = new SharedPerlUndef;
OTOH:
share($var);
may need to morph $var into a shared reference, with an additional
indirection and memory overhead.
(I don't know, what Perl5 does with an already used "$var", that is
turned into a shared var later - or even at runtime).
So the overhead is only the necessary locking, the indirection can
easily be avoided.
> Liz
leo
