It is a misunderstaning that reference counting always causes immediate garbage collection. There are different algorithms, and counting reference is much more complex than you thought. As a matter fact, in order to resolve problems including cyclic garbage, Perl uses Deutsch and Bobrow's deferred reference counting. This algorithm ignores updates to local variables, and it periodically scans the stack to determine the true reference counts.

Can you find documentation of this claim? The Perl documentation that I've read says that Perl uses classic reference counting and does not handle circular garbage (until it has to free everything when it exits). Which is why we have Devel::WeakRef.

For instance see Reference Counts and Mortality in perlguts or Two-Phased Garbage Collection in perlobj. You can verify what that says by experimenting with DESTROY methods. They exhibit reliable behaviour that they wouldn't if true GC were in use. Else my ReleaseAction wouldn't work as advertised.

What's the reason for having ReleaseAction when End already exists on CPAN (and was uploaded before)? If there is no profound reason, why not deprecate one of them and incorporate it in the other?

ihb

Read argumentation in its context!

I'm not sure where you got this information from, but it isn't true. Perl5 uses simple immediate reference counting, and if you remove your last external reference to a cyclic structure without breaking the cycle you'll leak that memory.

Some additional optimisations are done: notably things pushed temporarily onto the main stack (eg function arguments) usually do not have their reference count increased to reflect the fact; this turns out to be the source of numerous bugs however, and as we've added more exceptions and workarounds to fix those the benefit has decreased to the point we're considering removing the optimisation altogether.

Perl6 has been designed from the start to use GC, but I don't know much detail about the precise flavour of GC used.

Hugo