Front page | perl.perl5.porters |
Postings from August 2010
Re: TPF bug-grant report #18
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
August 1, 2010 14:04
Subject:
Re: TPF bug-grant report #18
Message ID:
20100801210406.GB3220@iabyn.com
On Thu, Jul 15, 2010 at 01:42:12PM +0100, Nicholas Clark wrote:
> 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:
> > > 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? :-)
Now done with commit 5648c0ae71de0db3ebfb4199727bc21e89c146c0 (and a
supporting cast).
>
> 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.
I've thought about this some more, and the only way I can see it working
is to add GvCV_set and GvGP_set macros, then make GvCV and GvGP rvalue-only
(like I did with CvGV). This is because if we start with the 'normal'
situation of not needing a backref, since CvGV(GvCV(gv) == gv, then we
need to know immediately if the GV stops pointing at the CV (by altering
GvGP or GvCV, (eg *f = *g, *f = \&g) and go and fix up the refcount of the
CvGV.
It strikes me that this would cause a lot of CPAN XS code to need fixing,
so I'm reluctant to proceed (even though its a clean solution that totally
removes the need for backref magic on GVs).
--
Never do today what you can put off till tomorrow.
Thread Previous
|
Thread Next