develooper Front page | perl.perl5.porters | Postings from April 2016

enable DPERL_OP_PARENT by default in 5.25.0?

Thread Next
From:
Dave Mitchell
Date:
April 6, 2016 14:42
Subject:
enable DPERL_OP_PARENT by default in 5.25.0?
Message ID:
20160406144237.GU4160@iabyn.com
The PERL_OP_PARENT optional compiler define was added in 5.21.2 (with
modifications in 5.21.11), and made it into production in 5.22.0.

I'm proposing that we make this the default in 5.25.0, and thus for
5.26.0 if there aren't any problems in the meantime - but with an
new build flag PERL_NO_OP_PARENT to optionally disable it again.

To refresh people's memories: currently in the op tree, all siblings of
the same parent node are linked with the op_sibling field, which contains
a pointer to the next sibling. For the last sibling this is NULL. With
PERL_OP_PARENT defined, the last pointer instead points back to the parent
node, and the lastness is instead indicated by a flag in the op. This has
two main advantages. First, it allows optimisers, tree mungers etc, (both
core and CPAN) to easily find the parent (or grandparent etc) of a node,
which is currently hard. Second, it will allow several tree-walker
functions in the core to avoid using recursion when traversing the tree.
This is currently a problem, as traversing a deep tree can easily blow the
stack and crash the process:

    eval '$b = ' . ('$a ? 1 : ' x 50_000) . '1';

which gives:

    $ perl5220o ~/tmp/p
    Segmentation fault (core dumped)

I'm not proposing that we do anything in the core before 5.26.0 that makes
use of this facility: e.g. improving optimisers or avoiding recursion
would be done in 5.27.0 onwards.

The main things which enabling PERL_OP_PARENT would affect are modules
that access or manipulate the optree, either directly in XS, or in perl
via the B interface.  When PERL_OP_PARENT was first introduced there was
some effort to get such modules to run on perls built with it, but I don't
know to what extent that's complete. If people are aware that this would
still be a big issue, then I'll withdraw this proposal. If people think
it's probably ok, then enabling it in 5.25.0 will give us plenty of time to
flush out any remaining problematic modules, but always with the ability
to back it out before 5.26.0.

-- 
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About