delete object

[Peter J. Holzer]

Indeed, Perl doesn't seem to free all the space immediately.

#!/usr/bin/perl

# 1652 perl ...
BEGIN { getc; }
my @array = (1 .. (1 << 22));
# 331360 perl ...
# huh? 80 bytes per an integer?

Interesting. It should be around 40 bytes on a 64 bit system (less on a
32 bit system). See http://www.hjp.at/programming/perl/memory/ for some
experiments I did with 5.8 and 5.10 a couple of years ago. Would you
mind running the test script on that page? (I just see that it accesses
/proc/$$/statm to get the (virtual) process size - if you don't run
linux, you'll have to change that).

getc;
print $#array, "\n"; # prints: 4194303
undef @array;
# 298640 perl ...

Note that the process shrunk only by 331360 - 298640 = 32720 kB, or
about 8 Bytes per element. That's size of the array itself. The elements
of the array (the other 72 bytes per element) were only returned to the
heap and are available for future malloc calls.

hp

 

[Peter J. Holzer]

Quoth (e-mail address removed):

You also need DESTROY when the object has internal circular references,
since they won't be collected until the cycle is explicitly broken.

I don't see how DESTROY helps here - if there are circular (non-weak)
references, the reference count will never reach 0 and DESTROY will
never be called.

What you need in this case is an explicit cleanup method which is called
explicitely.

hp

 

[Xho Jingleheimerschmidt]

I don't see how DESTROY helps here - if there are circular (non-weak)
references, the reference count will never reach 0 and DESTROY will
never be called.

If the root object is not itself part of the cycle, then DESTROY will
get called on the root object which then gets to break the cycle among
its children.

Xho

 

[Rainer Weikusat]

[...]

For example, a bug which was fixed in 5.14 but before that will segfault
perl, probably back as far as 5.000:

perl -MDevel:eek -e'my $x = sub { 1 };
delete $main::{__ANON__};
Dump $x;
'

This segfaults because the sub holds a pointer to its glob, in this case
*__ANON__; but this pointer isn't refcounted, because (at least in the
named sub case) the glob also holds a pointer to the sub, so there would
be a cycle.

Nope. This isn't refcounted because this would be pointless in case of
a named sub since the glob already holds a refcounted pointer to the
sub. For obvious reasons, a mechanism designed based on the assumption
that there will always an 1:1 mapping between different kinds of
objects can't just be 'extended' to the 1:n case without changes.

I'd like to expand a little on that: There's an obvious reason why a
glob should hold a refcounted pointer to a subroutine associated with
the name mapped to this glob: Like any other kind of Perl object, the
subroutine is supposed to go away once it isn't referenced anymore and
the glob pointer is one of the anchors keeping it in 'known space':
For as long as the subroutine is still associated with the name in
question, it can still be called. OTOH, having a back pointer from the
CV to this one particular glob seems to be singularly weird design
descision since any number of names may resolve to the same
subroutine and may be associated with and disassociated from it at any
given time. Consequently, I would really like to know why a named
subroutine has a pointer to the glob originally pointing to it: To me,
this looks very much as if it was either and ill thought-out attempt
at 'optmizing' something or simply a design error.