in reply to "goto" memory leak

Strictly speaking, it's a not a leak: the memory is reclaimed on scope exit. This code doesn't grow in memory usage after the first iteration of the while loop: 
while (1) {
    $i = 0;
  again:
    my $x;
    goto again if $i++ < 100_000_000;
}

[download]
Part of the run-time action of 'my' is to make a note to free the lexical at scope exit. The goto causes additional notes to be pushed on the savestack without any scope being exited. When the scope is finally exited, all the notes are popped off the savestack and processed.

Dave.

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

    That depends on how you define "memory leak".

    At least under Wikipedias definition ("In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations1 in such a way that memory which is no longer needed is not released.") this still is a leak. Because the main scope is never exited (while the program is running) there is at least one scope that never releases its memory.

    And then there are closures. See the following code that also exhibits the memory leak:

    #!/usr/bin/perl

my $i;

top:

while (1) {
  again:
    my $x;
    $i = 0;
    goto again if $i++ < 100_000;
}

goto top;

    [download]

    Necessarily the hook variable has to be in the main scope (I assume), but the interesting thing is that the code seems to be minimal for the closure case, i.e. $i creates the closure, but $x is needed to create the leak.

    UPDATE:Anon Monk found a silly mistake in my code, the inner goto is an endless loop. The conclusion is wrong, I tested closures with teh following code and memory stayed low. 

    
sub closure {
        my $s;
        return sub { $s=5; my $i; }
    }

    my $f = closure();

while (1) {
    $f->();
}

    [download]
[reply]
[d/l]
[select]

      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).

[reply]
[d/l]
[select]

        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]

      That snippet exhibits an infinite loop, or two. The goto is always taken since $i++ < 100_000 will always be true...

      Objects may have side effects when they are DESTROYed, so this must happen at some well-defined moment (scope exit). Gotos cannot create scopes as there is no way to determine the flow of the program.

[reply]
[d/l]

In Section Seekers of Perl Wisdom