develooper Front page | perl.perl5.porters | Postings from October 2014

Shared padlists

Thread Next
Father Chrysostomos
October 28, 2014 05:34
Shared padlists
Message ID:
On and off over the past few years, I've been thinking about possible
ways to fix the bless sub {} bug.  (Blessing an anonymous sub that is
not a closure causes future evaluations of the sub{} expression to
return a blessed sub, except under the debugger.)  The reason this
can't be fixed is that cloning a sub for evaluation of sub{} signifi-
cantly slows things down.

So I wondered why cloning subs was so slow and concluded that it was
pad cloning that was the real bottleneck.  That was why I made clones
share name pads a couple of years ago.

Well, I've just had a brainwave:

If we could extend padlists to hold a boolean indicating whether the 
sub is being called (i.e., !!CvDEPTH), then we could make sub clones
share padlists.  If the padlist is in use when a sub is about to be
called (and the sub itself has a CvDEPTH of 0), then that means the
padlist is shared with another sub that is currently running, so it
needs to be cloned.  The sub we are calling then keeps its own pad-
list from that point on.

That should allow closures to be cloned more quickly.  I imagine that
most closures from the same prototype do not call each other.  So it
would save memory, too (assuming that the increase in the size of the
padlist struct does not offset it).

And then maybe we could fix the bless sub {} bug once and for all.

We would have to take special care when it comes to subs with
state vars.


(I imagine only Dave Mitchell will know what I am talking about,
though I hope that is not true.  [And by that I do *not* mean that I
hope he does not know either. :-)])

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