On Thu, 2002-05-16 at 16:07, Mike Lambert wrote:
> > Languages like perl can't easily be inlined, since subs may be
> > redefined at any time. If a sub's a leaf sub you can detect changes
> > before calling safely, but if it's not a leaf sub you run into the
> > potential issue of having the sub potentially redefined while you're
> > in it.
>
> If I'm in middle of executing function A, and I redefine function A, then
> it doesn't matter for the execution of the function. Even un-inlined, the
> execution continues as it did before. Perhaps this should be an argument
> to appease the callee-save proponents. Their main argument was leaf subs.
> If we can guarantee that these are inlined, then their only argument goes
> away. :)
Hmm... I see some conversational double-speak there, but I don't recall
the thread. Point granted.
> As such, I think we should be able to inline a call to A() with:
> if( value A == value of A when we inlined it )
> contents of sub
> } else {
> A()
> }
Yes, in the default case I think that's what was being discussed.
> Alternately, I think we should be able to mark subs as 'final' or 'inline'
> to indicate our guarantee that they won't be modified. Of course, it'll
> conflict with auto memoizing or auto currying modules that'd want to
> override it, but that's their fault. :)
Yes, I suggested "inline" or "const".... I can't imagine that we would
want to do without this, regardless of what we call it. Otherwise,
auto-accessors will always be slower than using the variable. Would
everyone agree that this property should default to being set for
auto-accessors?
> And even though distributed .pbc files and seperate compilation are some
> goals of perl6, I still think we're okay. If we inline a function in
> module A, and module A changes, Perl6 should ensure that the original
> version is still loaded for our code, and thus our inlining should still
> be valid.
Oh, that one's easy (I think/hope/pray).
There're three stages:
1. "compile time" -- When a module or program is byte-coded
2. "load time" -- When byte-code is loaded off of disk
3. "run time" -- When the program begins to execute
There are complexities, but you get the idea. "Load time", I assume is
also when BEGIN executes.
In this model, you only ever inline at load time ***OR*** when the
compiler is attempting to produce a self-contained byte-code executable
(e.g. one which has all of the modules in it), in which case it executes
that part of the load time process early. If you like, call this a
sub-stage of load time, which I shall dub "link time". Link time can
only happen once per program, so it must happen when we actually know
what all of the program components are.
Any other way of doing this would seem to me to be a very dangerous
weapon to brandish so close to so many unsuspecting feet. :-(
> Another avenue is that of self-modifying code. I know it would break
> threads, or cause code duplication between threads, but when A changes, we
> can either re-inline the new subroutine, or eliminate the 'if-else' check
> to avoid the branch we know will be false from then on. Creating code
> which optimizes itself as it's run based upon internal profiling would be
> cool. But that's the topic of a different thread. :)
Code that does this by changing sub references should still work. Code
that does this by changing its own internal representation gets what it
paid for.
