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