Front page | perl.perl5.porters |
Postings from December 2014
Perl's memory allocator is very keen to re-use recently freed memory
slots:
$ perl -E 'for (1 .. 10) { my $arr = []; say $arr; }'
ARRAY(0x1cdb0a0)
ARRAY(0x1cdb0a0)
ARRAY(0x1cdb0a0)
...
Normally this is quite useful, but in one specific case it keeps
getting in the way.
Devel::MAT currently allows only one major mode of operation - that of
taking a single "atomic" (from perl's perspective) snapshot of all the
memory, and writing it all out in one large file for later analysis by
one or more "offline" tools. While this is useful and allows lots of
bugs to be found, there's a whole class of behaviours that can't
currently be traced, because that would require the use of two
snapshots taken at different points in time from the same perl
process, to compare between.
Because Perl re-uses SV addresses quite so keenly, it makes it hard to
perform any meaningful analysis by comparing two different snapshot
files. If Perl had a way to temporarily disable that memory reuse,
perhaps by deferring the actual reclaiming of SV slots when the
refcount hits zero, then Devel::MAT could use that to ensure that no
memory address it wrote in its first dump file would be a candidate for
reuse for a different SV by the time the second is written. Any
addresses in common to both files would therefore necessarily be the
same SV.
-----
In summary:
I'd like control over the way that SV allocation reclaims memory
addresses, temporarily preventing addresses getting reclaimed and
reused, until such time as I switch it off again.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
Thread Next