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


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

there is at least one scope that never releases its memory.

In your original program, yes. It never releases memory, but that memory is still needed. That doesn't meet the definition of a leak.

Keep in mind that the run-time effect of 

my $i;

[download]
is similar to 
Hook::Scope::POST(sub { $i = undef });

[download]

It pushes an instruction on the stack to clear the scope on exit (which could happen, say, if an exception occurs).

Replies are listed 'Best First'.
Re^4: "goto" memory leak
by jethro (Monsignor) on Mar 30, 2016 at 14:24 UTC

    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.

[reply]
      "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]

      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]

In Section Seekers of Perl Wisdom