develooper Front page | perl.perl5.porters | Postings from July 2010

Re: TPF bug-grant report #18

Thread Previous | Thread Next
Nicholas Clark
July 15, 2010 05:42
Re: TPF bug-grant report #18
Message ID:
On Thu, Jul 15, 2010 at 12:07:14PM +0100, Dave Mitchell wrote:
> On Thu, Jul 15, 2010 at 10:59:06AM +0100, Nicholas Clark wrote:
> > On Wed, Jul 14, 2010 at 11:30:45PM +0100, Dave Mitchell wrote:
> > > I've now pushed my work so far, to get it some smoky love.
> > > The basic fixes are all in place: all of GvSTASH, SvSTASH and CvGV are now
> > > always correctly handled (as far as I'm aware). There's one slight issue
> > > with EGV still, and I have a number of bits of cleanup, optimisation and
> > > documentation still to do.
> > 
> > Woohoo!
> > 
> > Definitely some level of optimisation desirable, as the correctness for
> > CvGV() currently comes at the price of a MAGIC structure and an AV per
> > subroutine in the symbol table.
> > 
> > In theory that could all be abolished and replaced by a flag bit, as the GP of
> > the GV that CvGV() points to is already pointing back to the PVCV ("we first
> > thought of"). Except that that then relies on anyone assigning to CvGV()
> > knowing to "do the right thing", which I believe now is cvgv_set(). But that
> > can be enforced by changing
> > 
> > #define CvGV(sv)	((XPVCV*)MUTABLE_PTR(SvANY(sv)))->xcv_gv
> > 
> > to
> > 
> > #define CvGV(sv)	(((XPVCV*)MUTABLE_PTR(SvANY(sv)))->xcv_gv + 0)
> > 
> > providing appropriate CvGV_set() macros in blead and ppport.h, and offering
> > patches to whatever CPAN code needs updating as a result.
> Ah, but its not that simple; its not just CvGV that needs protecting. For
> example in the following:
>     sub f {}
>     my $r = \&f;
>     Dump $r;
>     *f = sub {};
> &$r becomes 'orphaned'; its CvGV still points to *f, but *f's CV slot now
> points elsewhere. So when *f is freed, it doesn't know to reset &$r's CvGV
> field. This is why I decided to concentrate on getting a robust solution
> working before trying to optimise.

Yes, I totally agree with that priority.

By "flag bit" I meant adding another flag bit to the GV, which if set signals
that the CV pointed to by GvCV() is has a weak reference to us.
And if clear means just the same as now - nothing special.
(But the GV can still have regular backreference magic stored)

> The other thing I wanted to look into was, for backref magic, when there
> is a single backref (that also happens not to be an AV), whether we could
> stick it directly in mg_obj, saving the cost of an AV.

This seems like a useful space optimisation, on the assumption that many
things only have one weak reference pointing to them. Why didn't I think of
it? :-)

However, once the code is known working good, I feel that it's worth exploring
something even more aggressive for GVs<=>CVs, as there are a lot of them, and
it doesn't feel that nice using 24 (or 48) bytes for every CV in the symbol
table, if we can avoid it.

Nicholas Clark

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