develooper Front page | perl.perl5.porters | Postings from February 2003

Re: [PATCH] jumbo closure fix

Thread Previous | Thread Next
Dave Mitchell
February 26, 2003 12:43
Re: [PATCH] jumbo closure fix
Message ID:
On Wed, Feb 26, 2003 at 11:03:18AM -0800, Gurusamy Sarathy wrote:
> >* run-time cloning is now a lot faster, eg $a = sub {$x} is 15% faster,
> >$a = sub {$x+$y} is 25% faster. This is because at compile time, the index
> >into the parent pad is recorded for each outer lex, so cloning just
> >involves grabbing each approriate value from the parent pad rather than
> >calling pad_findlex() for each outer lex.
> How does this interact with recursion?  It sounds like the behavior
> may be significantly different now...

It shouldn't make a difference, since fake lexicals are copied to each pad
frame during recursion, and all we're doing is the optimisation of
pre-computing the index rather than letting pad_findlex() determine the
same (constant) value each time round. We can do this optimsation now
beause all subs capture, not just anons, so the requried value is always
to be found in the directly lexicially enclosing pad, as opposed to
several levels up.

(Just to clarify: we're pre-computing the index (a small integer), rather
than a pointer to the captured SV.)

> >* warnings are changed and more pervasive:
> >
> >the warning 'Variable \"%s\" may be unavailable' is now the more assertive
> >'Variable \"%s\" is not available', and some cases that formerly caused
> >this warning now cause 'Variable \"%s\" will not stay shared' instead, and
> >vice versa. Several cases that formerly quietly did something strange
> >(usually involving a mysterious shared undef value), now give the 'is not
> >available' warning.
> I never really liked the original warnings, so I'm not sure I like
> escalating the frequency of them. :)
> IMO, the original warnings are rather misguided, because they
> ass_u_me a particular intent which may not be (in fact most
> often isn't, given that most people aren't trying to do anything
> fancy with closures) true.  It may be better to let these
> variables resolve as normal and let "use strict" do its thing.

What is the thing that you want 'use strict' to do?

> >* There's a new global variable PL_cv_has_eval, that gets set during
> >compilation if any eval-like constucts are found within the CV's ops.
> Not sure of the implications of this.  Does this set up
> action-at-a-distance scenarios (in the sense that adding an
> eval"" into a piece of code makes it suddenly behave differently)?
> Or is it purely an optimization?

It's just turning off an optimisation. Ie, we used to share the anon
prototype only if it had no outside lexicals; now in addition, we avoid
this optimisation if the anon sub lexically contains any code that could
trigger an eval which would cause pad_findlex() to search back up the
chain, suddenly making the anon behave like a closure. Eg we say that

    sub { sub { sub { eval '...' } } }

is as 'dangerous' as (in fact even more dangerous than)

    sub { sub { sub { $x } } }

and so at compile time pessimise by settting CvCLONE() on those 3 anon

> I hope code doesn't behave differently inside the debugger vs
> outside it.

It shouldn't do, barring bugs. All it's doing is pessimising under -d.
This contrasts with the old behaviour of the debugger, which could
actively modify the pads of non-closure anon-prototypes, and turn them
into closures at run-time.

> Excellent work, keep it up.

Thanks, I will (perhaps :-)

"I do not resent critisism, even when, for the sake of emphasis,
it parts for the time with reality".
Winston Churchill, House of Commons, 22nd Jan 1941.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About