develooper Front page | perl.perl5.porters | Postings from January 2003

Re: Freeing code

Thread Previous | Thread Next
Rafael Garcia-Suarez
January 28, 2003 02:20
Re: Freeing code
Message ID:
"Paul Johnson" <> wrote:
> >
> > op_seq seems to be used only as a flag : "has this OP been optimized by
> > now"
> It is also used by B::C.  The value -1 is a flag to indicate that an op is
> statically defined and should not be freed.

So we could theorically replace op_seq by two boolean flags, as far as
the core and the bytecode compiler backend are concerned.

> >> Removing the -1 condition doesn't cause any obvious test failures.
> How are those compiler tests?  :-/

I didn't run the special compiler test target.

> > Moreover, turning op_seq from a counter into a boolean flag doesn't cause
> > any test failure either (except for B::Concise of course, that uses
> After the optimisation phase it is not required.  Indeed, B::Bytecode has
> an option not to fill in that field.
> > the value of op_seq in its output). op_seq is not related to cop_seq,
> > and I suspect it's obsolete.
> I use it in Devel::Cover in conjunction with the address of the op in
> order to (almost) uniquely identify the op.  Without this when ops get
> freed and the address is reused they cannot be told apart.  I believe that
> Devel::Dprof also suffers from this problem, though maybe there is a
> better solution.

B::Concise also uses it to identify ops.

--- op.c        (revision 622)
+++ op.c        (working copy)
@@ -224,6 +224,8 @@
     register OP *kid, *nextkid;
     OPCODE type;
+    /* The special value -1 is used by the B::C compiler backend to indicate
+     * that an op is statically defined and should not be freed. */
     if (!o || o->op_seq == (U16)-1)
End of patch.

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