At 09:47 AM 11/7/2001 -0600, Dave Goehrig wrote:
> > The problem with inlining methods from PMC vtables is it assumes those
> > vtable methods are constant. They're not.
>
>They're not constant universally, but the are constant locally.
No, they aren't. A vtable method can completely swap out a variable's
vtable and substitute one that does something else entirely.
>I'm not saying that we are going to win all the time, or that this isn't
>tricky, or even that we SHOULD do it. What I'm saying is I think
>the potential payout (especially if one ever starts compiling direct to bare
>hardware) may be worth the cost of a rethink.
You're dancing with the optimizer. I've already done that dance more than
once. There's a remarkable amount of stuff that's not safe to do with perl
code. The amount of certainty you get is potentially very small.
> > The only time we can safely bypass the vtable indirection is when all of
> > the following are true:
> >
> > *) The program is fully parsed
>
>If the program isn't parsed fully enough that we don't know what
>something is that means that we may not be able to reasonably inline it.
>It means inlining is a high risk activity, if we do it, we'll have
>to undo it when we parse the bit that tells us that we shouldn't
>have done it orignally.
>
> > *) There are no string eval, do, or requires
>
>As soon as you generate code on the fly, or have code which modifies
>other code, you're already whipping out the assembler again.
You're whipping out the full compiler, not just the assembler. (We probably
won't ever whip out the assembler, thinking about it) And potentially
rebuilding a block of code you're in the middle of.
> The trick
>would be figuring out what nastiness the new compilation brings with
>it. When the eval'd string is compiled is may not do anything that would
>kill existing vtables. Basically this is the same argument as your
>first point...
>
> > *) There are no symbolic references on the LHS of any assignment
>
>I would appreciate it if you explain this further, the rationale.
If there's a symbolic reference on the LHS, then the assignment can
potentially require a full rethink of everything at runtime. What do you do
if the LHS evaluates out to @foo::ISA and you just changed the inheritance
hierarchy of all foo objects, potentially invalidating and rebuilding the
foo vtable? Or worse yet, if you suddenly change the definition of
SCALAR::+ and now all scalars have a new addition vtable that does string
concatenation instead of addition?
Since you don't know, you can't assume it'll do something safe. And while
it's potentially possible you just de-optimize code, it's fairly
non-trivial to recompile a block you're already in the middle of,
especially if you're in the middle of another block (like a sub) and need
to rebuild a parent block such that you can still return to the spot you
left from. (Try it when the code that triggers the recompile is caused by
accessing a tied variable so that you're rebuilding an expression you might
be in the middle of)
>Some times we want to use vtablesness, but I can't see how this negates
>all applications of inlining.
>
> > *) There is no use of MY within the block or in any subs called by
> the block
>
>I don't see what you are implying here. Could you explain this a bit more?
MY lets you mess with the lexical scratchpad, either yours or a callers. If
it's used, including in subroutines you call, it can potentially change the
type of variables in your scratchpad, and that means they may, probably
will, behave differently.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
