Front page | perl.perl5.porters |
Postings from July 2010
Re: TPF bug-grant report #18
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
July 15, 2010 05:42
Subject:
Re: TPF bug-grant report #18
Message ID:
20100715124212.GG48531@plum.flirble.org
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