Sorry for the delay. I got into something else and overlooked this. Try this version of your code:

use strict;
$| = 1;
print "$$\n";   #top -p $$

print "Test, Allocating a large string \n"; <>;
{
    my $foo = 'X';
    $foo x= 100000000;
    print "Large String allocated.\n";<>;

    undef $foo;
    print "Large String deallocated.\n";<>;
}

print "2nd Large String.\n";<>;
{
#evil:    my $foo2 = 'X' x 100000000;
    my $foo2;
    $foo2 .= 'x' x 100_000 for (1 .. 1000);
    print "2nd Large String allocated.\n";<>;
    undef $foo2;
    print "2nd Large String deallocated.\n";<>;
}
print "Now what? Press enter to exit";
<>;
[download]

When that reaches the "Now what" prompt, you should find that the memory usage has return to the same level as you had at statrtup with all the large allocations now returned to the OS.

The main change is my $foo = 'X'; $foo x= 100_000_000;, rather than my $foo = 'X' x 100_000_000;.

With the latter version, the big string is constructed on the stack, and then assigned to the scalar $foo, with the result that it makes two large memory allocations, one of which never gets cleaned up.

With the former version, that double allocation is avoided and the memory is cleaned up properly.

Note. The minor change to the second loop 1_000x100_000 rather than 100_000x1_000 makes no difference to the outcome, I just got bored waiting for the loop to run :)

The duplication of the allocation using the second method isn't an error, but rather a side effect of the way the code is parsed and executed. The fact that it doesn't get cleaned up properly could be construed as a bug--or not. You'd have to raise the issue with p5p and take their view on the matter.