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

Re: Freeing code

Thread Previous | Thread Next
Paul Johnson
January 28, 2003 02:00
Re: Freeing code
Message ID:

Rafael Garcia-Suarez said:

> Dave Mitchell wrote:
>> It turns out that one in every 64K ops will not be freed, due to the
>> following:
>>     Perl_op_free(pTHX_ OP *o)
>>     {
>> 	register OP *kid, *nextkid;
>> 	OPCODE type;
>> 	if (!o || o->op_seq == (U16)-1)
>> 	    return;
>> The "o->op_seq == (U16)-1" condition was added somewhere between
>> 5.003_22
>> and 5.004_05, and I have no idea what it's for.
>> op_seq seems to get set from PL_op_seqmax, which only seems to get
>> incremented in Perl_peep, and which of course soon wraps round in the
>> presence of evals in a loop.
> 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.

>> Removing the -1 condition doesn't cause any obvious test failures.

How are those compiler tests?  :-/

> 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.

Paul Johnson -

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