[perl #78194] Referencing a PADTMP twice produces two copies

On Wed Aug 14 09:27:13 2013, bulk88 wrote:
> On Wed Aug 14 09:11:42 2013, ikegami@adaelis.com wrote:
> > On Wed, Aug 14, 2013 at 11:24 AM, bulk88 via RT
> > <perlbug-followup@perl.org>wrote:
> >
> > > On Tue Aug 13 13:46:33 2013, sprout wrote:
> > > >
> > > > And I applied that patch, with a slight tweak (with one arg it
> was
> > > > leaking ops), as 34b94bc4d.
> > > >
> > >
> > > The patch

(He means 3455055fa; see below.)

> > > looks inefficient. Every XSUB call now has a larger
> overhead.

True, but the overhead is minuscule, just a quick scan and flag check in
most cases.  This is less than the argument-processing overhead of most
XSUBs.

An alternative would be to fix this bug by having newRV copy anything
marked PADTMP, but then newRV_noinc would have to SvREFCNT_dec its
argument, leaving the caller with a pointer to a freed SV.  That would
result in subtle bugs hard to diagnose.

Another way would be to modify ops that return PADTMPs not to return
them in lvalue context to begin with, but that would shift the
complexity elsewhere into many pp_ functions, including pp_const which
is hotter than pp_entersub.

> > Why do you think so? Do you think S_ck_dump gets called for every
> XSUB
> > call? Isn't it only called for calls Devel::Peek::Dump (and imports
> > thereof)?
> >
> > +    CV * const cv = get_cvn_flags("Devel::Peek::Dump", 17, 0);
> > +    cv_set_call_checker(cv, S_ck_dump, (SV *)cv);
> 
> Whoops, I meant the patch in
>
http://perl5.git.perl.org/perl.git/commit/3455055faace06645b99a6ed63fce90144ab47e1
> which claims to be part of this ticket. I didn't compare the SHA1s.


-- 

Father Chrysostomos

• [perl #78194] Referencing a PADTMP twice produces two copies by Father Chrysostomos via RT