Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^2: when is destroy function called

by roboticus (Canon)
on Mar 02, 2013 at 15:43 UTC ( #1021435=note: print w/ replies, xml ) Need Help??


in reply to Re: when is destroy function called
in thread when is destroy function called

Athanasius:

I lean towards the first reading. I think the reason that the destroy method executes after print completes is because a reference to the object is placed on the stack, and the reference count goes to zero when the parameters are cleared from the stack.

Calling destroy immediately is simpler than maintaining a to-do list for later processing. If I were to write perl, I'd choose the simpler method. (Of course, I can't offer any evidence either way--it's just my gut feeling.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.


Comment on Re^2: when is destroy function called
Re^3: when is destroy function called
by Athanasius (Monsignor) on Mar 02, 2013 at 17:28 UTC

    roboticus:

    I think the reason that the destroy method executes after print completes is because a reference to the object is placed on the stack, and the reference count goes to zero when the parameters are cleared from the stack.

    So the idea is that DESTROY is called immediately when the reference count falls to zero, but that the decrementing of the reference count does not occur immediately upon the call to undef? That sounds reasonable, but I’m not sure which stack is meant. It can’t be the subroutine’s parameter list:

    #! perl use strict; use warnings; { package Foo; sub new { return bless {}; } sub DESTROY { print "Foo::DESTROY\n"; } } my $foo = Foo->new(); bar($foo); print "Back in main\n"; sub bar { print "Begin bar()\n"; undef $_[0]; print "End bar()\n"; }

    Output:

    3:14 >perl 556_SoPW.pl Begin bar() Foo::DESTROY End bar() Back in main 3:18 >

    Can you clarify what you mean by “a reference to the object is placed on the stack”?

    Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

      Athanasius:

      Yeah, I could've been more clear...

      I meant that when setting up the print statement:

      print 'My enemy must ', $enemy->obey(), undef($enemy), '. His phaser is named ', $phaser->{name}, eval('$enemy->exterminate()'), ". Bye!\n";

      that I suspect that perl may be putting a reference to the thing $enemy refers to on the stack for the purpose of calling the obey() method (and possibly for the undef thing, too). So that we'd have something like this:

      *** Before print statement *** $enemy------------------------->Dalek:{phaser=> + } (ref=1) | +---------------+ v $phaser------------------------>Phaser:{name=> + } (ref=2) | +--------------+ v 'Exterminator' (ref=1) argument stack: -empty- *** After print setup, before print executes *** $enemy------------------------->Dalek:{phaser=> + } (ref=2)<-+ | | +---------------+ | v | $phaser------------------------>Phaser:{name=> + (ref=2) | | | +--------------+ | v | 'Exterminator' (ref=2) | ^ | +--------------+ | argument stack: '. Bye!\n' | | eval('$enemy->exterminate()' | | ref---------------------------+ | '. His phaser is named ' | undef($enemy) | obey()<-ref---------------------------------+ 'My enemy must '

      At this point, I'm guessing the stack contains a reference to the Dalek that $enemy also points to, so it can call the obey method.

      *** Executing through print, just after undef step *** $enemy--->undef Dalek:{phaser=> + } (ref=1)<-+ | | +---------------+ | v | $phaser------------------------>Phaser:{name=> + (ref=2) | | | +--------------+ | v | 'Exterminator' (ref=2) | ^ | +--------------+ | argument stack: '. Bye!\n' | | eval('$enemy->exterminate()' | | ref---------------------------+ | '. His phaser is named ' | undef($enemy) | obey()<-ref---------------------------------+ 'My enemy must '

      Here, we've already executed the obey() method so the string gets printed, and we've just executed undef, so the link between $enemy and the Dalek is now broken. But the argument stack for print still holds the reference to the Dalek.

      *** Print just finished, now removing items from stack ... *** $enemy--->undef Dalek:{phaser=> + } (ref=1)<-+ | | +---------------+ | v | $phaser------------------------>Phaser:{name=> + (ref=2) | | | +--------------+ | v | 'Exterminator' (ref=1) | | argument stack: obey()<-ref---------------------------------+ 'My enemy must '

      Most of the argument stack for the print statement is gone, the next item to go is the reference of interest. (Note: the reference count to the 'Exterminaor' string has already dropped back to 1.) So perl dutifully reduces the references count for the item on the stack, and notices the count went to 0:

      $enemy--->undef Dalek:{phaser=> + } (ref=0)<-+ | | +---------------+ | v | $phaser------------------------>Phaser:{name=> + (ref=2) | | | +--------------+ | v | 'Exterminator' (ref=1) | | argument stack: obey()<-ref---------------------------------+ 'My enemy must '

      ...at which point it tells the Dalek to go DESTROY itself. While it destroys itself, it discards the reference to the Phaser (reducing its reference count):

      $enemy--->undef Dalek:{phaser=> } (ref=0)<-+ | $phaser------------------------>Phaser:{name=> + (ref=1) | | | +--------------+ | v | 'Exterminator' (ref=1) | | argument stack: obey()<-ref---------------------------------+ 'My enemy must '

      The Phaser still has a reference, so it's going to stick around. When the DESTROY method returns, perl then frees the Dalek memory, and continues to remove items from the argument stack:

      $enemy--->undef {FREE MEMORY } $phaser------------------------>Phaser:{name=>'Exterminator'} (ref=1) argument stack: 'My enemy must '

      I guess I should've put a reference count on the 'Exterminator' string, as well, but I didn't think of it until after I drew all of that, and I'm not quite ambitious enough to fix that oversight.

      Here's a bit of code I came up with in an attempt to lend some weight to my theory. It's not proof, as I can't think of a way to examine the variables in the middle of stack cleanup (short of running perl under gdb):

      The results are a bit tedious to read through, though:

      Update: I went ahead and updated the diagram to show the reference counts for the 'Exterminated' string as well. It make the node a bit longer, but I think it helps illustrate things. I also added a couple readmore tags to make a long post somewhat shorter.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

        Hello roboticus,

        Thanks for taking so much trouble in your explanation! I’ve been trying — with limited success :-( — to wrap my head around it for about a day now, which is why I haven’t replied sooner.

        I’m confused by this:

        Here, we’ve already executed the obey() method so the string gets printed, and we’ve just executed undef, so the link between $enemy and the Dalek is now broken. But the argument stack for print still holds the reference to the Dalek.

        I would have expected that each argument is popped from the stack as it is processed, so that its reference count is decremented as it leaves the stack. But I admit I don’t really know how all this works.

        Your use of Devel::Peek is interesting. (Incidentally, I think the expression ${shift}->{theVal} should be shift->{theVal}?) Looking at the reference counts, I can’t see the increment you predict between “before print” and “Do the print” — what should I be looking at?

        I did find this in the section Reference Counts and Mortality in perlguts:

        There are some convenience functions available that can help with the destruction of xVs. These functions introduce the concept of "mortality". An xV that is mortal has had its reference count marked to be decremented, but not actually decremented, until "a short time later". Generally the term "short time later" means a single Perl statement, such as a call to an XSUB function.

        If that passage is relevant to the situation we’ve been discussing, it supports your idea that it is the decrementing of the reference count to zero which is delayed until the print statement completes, and that, when the reference count reaches zero, the destructor is called immediately.

        Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1021435]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2014-09-18 02:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (105 votes), past polls