develooper Front page | perl.perl5.porters | Postings from February 2023

Re: PERL_RC_STACK branch: first cut

Thread Previous | Thread Next
From:
demerphq
Date:
February 27, 2023 08:07
Subject:
Re: PERL_RC_STACK branch: first cut
Message ID:
CANgJU+WLR3fjokDdzJcDpY0u8Kbg6+F-jHdduob_eMDWrDNkgw@mail.gmail.com
On Mon, 27 Feb 2023, 08:40 Vadim V Konovalov via perl5-porters, <
perl5-porters@perl.org> wrote:

> > TL;DR:
> >
> > The branch containing the first stage of my "make the stack ref-counted"
> > work is nearly ready for merging. In a default build, the core is mostly
> > unchanged: only when built with -DPERL_RC_STACK does it behave
> > differently. It needs testing on Windows. I need to decide whether to
> merge
> > soon or wait until after 5.38. Once in core it will affect people
> > who write or
> > modify PP functions. Currently an RC build runs about 20%
> > slower; the second
> > stage of this work will to optimise things - I expect
> > this to make an RC perl
> > run at about the same speed as a standard perl. At
> > the bottom of this email is
> > a cut+paste from a new section in perlguts
> > which explains how it works. I'm not
> > sure how the API functions get added to ppport.h.
>
>
> Quick TLDRs questions
> - what's the benefit? Does it fix bug


It should fix a longstanding set of bugs which cause segfaults and other
undefined behavior. The class of bugs it fixes is the number one cause of
fuzz generated segfaults and is a repeated, perhaps even number one cause
of segfaults in other contexts.

Look into our issue list for "stack not refcounted" or similar terms, I
expect you will find dozens of tickets.


or introduce nice new feature? Payment is high (in terms of speed 20%) so I
> guess the benefit is huge :)
>

My understanding is that some of the speed hit will go away as this logic
is stabilized. Anyway, the old adage applies: it is easy to be fast if you
don't have to be correct.

Fwiw, one reason that many languages are garbage collected and not
refcounted is that for tight loop code refcounting can be a significant
cost. Eg, consider a function that increments a member of a datastructure.
In a refcounted language that single increment becomes two increments and a
decrement, so 3x the cost /at least/.

Perl has historically avoided some of this cost by not refcounting the
stack, but to fix a bunch of refcounting issues /that/ causes there are
other expensive workarounds that get used. The general assumption is that
by refcounting the stack properly we can do away with the other work
arounds and end up net neutral, or maybe even net better off.

Cheers
Yves

Thread Previous | 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