http://qs321.pair.com?node_id=1159139


in reply to Re^3: "goto" memory leak
in thread "goto" memory leak

Ok, but again we could argue over the definition of the word "needed". "Needed" by the program writer or "needed" by an implementation that keeps scopes around that are not accessible to the program writer anymore? EDIT: Ok, POST is a way to actually access such scopes, maybe even other introspection code, but the question is whether there is a need to create and keep these scopes at all when the writer does not indicate he wants them around?

I'm more than happy with renaming the problem to "goto creates spurious scopes". The question that I can't answer is whether "goto" does that for a good reason, like "goto is harmful, and has to do this to jump in and out of nearly arbitrary scopes", or that it really is a bug.

Replies are listed 'Best First'.
Re^5: "goto" memory leak
by dave_the_m (Monsignor) on Mar 30, 2016 at 18:27 UTC
    "goto creates spurious scopes".
    No, goto doesn't create scopes, spurious or otherwise. There aren't any hidden or misbehaving scopes here. It's a bit like the following code: 
    while (1) {
    $i = 0;
    my @a;
  again:
    push @a, 1;
    goto again if $i++ < 1000;
}

    [download]
    In that code, there are only two scopes: the implied whole-file scope, and the while loop. The array will repeatedly have 1000 elements pushed on it, then be emptied.

    The goto just moves execution around to various places within the one scope.

    Perhaps the confusion is seeing 'my' as just a compiler declaration, like 'int' is in C; it's not; its something that has a runtime effect as well as a compile-time effect. If you repeatedly execute the 'my' without ever leaving the scope which that 'my' is embedded in, then that runtime effect will accumulate.

    Dave.

[reply]
[d/l]

      Thanks, much clearer now what is happening.

      Still my argument stands, a bazillion code snippets to free the same single memory location is (at least from the perspective of the script writer) a memory leak. The questions is only if it is advisable to fix it since the fix would probably incur a heavy runtime cost.

      It will only affect long running polling code in a few specific cases (for example microcontroller scripts to measure environmental stuff could fall into the trap). It is avoidable but the program writer would need to know information about an implementation detail of "my" that is not in the man pages at the moment.

[reply]

        If it's any easier, think of my as malloc(). Inside a while loop, the my variable goes out of scope each iteration, so the storage may be reclaimed. To get the same effect with a goto loop, you'll need explicit block scoping: 

        again:  {
                my $h;
        }

goto again;

        [download]

[reply]
[d/l]
[select]
Re^5: "goto" memory leak
by ikegami (Patriarch) on Mar 31, 2016 at 02:40 UTC

    I'm more than happy with renaming the problem to "goto creates spurious scopes".

    goto doesn't create any scopes. As I've already stated, the memory is being used when my is executed since that causes it push an instruction on the stack.

    Ok, but again we could argue over the definition of the word "needed". "Needed" by the program writer or "needed" by an implementation that keeps scopes around that are not accessible to the program writer anymore?

    The instruction is needed because it's virtually impossible to tell that the scope will never exit.

    • A lot of things can throw exceptions.
    • Including signal handlers.
    • The program can change while it's running.

    Even in the simplest cases, it would be extremely expensive to check, especially since this check would have to be performed at run-time.

[reply]
[d/l]
[select]

      Very true, it is impossible to check for scope exit. But would it be possible to check somehow (with a flag attached to the variable for example) whether the my variable already has a "destroy" POST routine on the stack or not?

[reply]
        That would require extra memory for each PAD entry, and would require extra time to exit a scope, just to avoid some rare degenerate case where someone uses bad coding practices. That would be a bad tradeoff.
[reply]

In Section Seekers of Perl Wisdom