Re: about FC commit "CV-based slab allocation for ops"

Daniel Dragan asked:
> So why does CvSLABBED have to be turned off before "if (slabbed)
> OpslabREFCNT_dec_padok(OpSLAB(CvROOT(cv)));" and/or
> "PAD_SAVE_SETNULLPAD();" executes, or in the CvSTART branch, before
> "opslab_force_free((OPSLAB *)CvSTART(&cvbody));" executes?

I remember having a reason for turning off the flag early, but now I
don't remember what it was.  It took me two weeks to write the patch
and get it right, so the reason may have ceased to be valid by the
time I finished.

Looking at the code now, I see a potential problem with turning off
the flag early:

    CvSLABBED_off(cv);
    if (!CvISXSUB(cv) && CvROOT(cv)) {
        if (SvTYPE(cv) == SVt_PVCV && CvDEPTH(cv))
            Perl_croak(aTHX_ "Can't undef active subroutine");

What if that croaks?  If I remember correctly, it's only the main cv
that doesn't forget its slab, and you can't undefine that.  So we
have no bug.  It's just less robust as a result of turning off the
flag early.

(Also, the SvTYPE(cv) == SVt_PVCV check is redundant and should prob-
ably be changed to an assert inside the if(CvDEPTH).  Formats can't
reach cv_undef with CvDEPTH set.)

> Can we leave the turning off of CvSLABBED flag until the very end of
> Perl_cv_undef_flags

I think so.

• about FC commit "CV-based slab allocation for ops" by bulk88
• Re: about FC commit "CV-based slab allocation for ops" by Father Chrysostomos