This is either platform specific, or a bug introduced since 5.8.6 because your code above (with the addition of a counter to display how many threads have been created and joined), doesn't leak on my system using 5.8.6 and threads 1.71:

use threads;
use strict;
use warnings;

print $], ' ', $threads::VERSION, "\n";

my $sub1 = sub { my $a=[ 1 .. 10000] };

my $m = 0;

for (;;) {
    printf "\r%d\t", $m++;
    my $thr = threads->new( $sub1 )->join;
    undef $thr;
}



__END__
c:\test>junk
5.008006 1.71
3077    Terminating on signal SIGINT(2)
[download]

For proof, see this image. It shows the cpu, memory usage and IO activity for the process while the code above created and destroyed those 3000+ threads. The memory usage wobbles up and down a bit, but basically stays level at around 2.7 MB.

I note also that in the same thread that you cited, that dave_the_m says that "the bug is fixed in bleed perl"?. (Unfortunately he didn't see fit to inform us of the cause, or the affected platforms:()

So, you could try either reverting to 5.8.6 or possibly upgrading to recently announced the 5.8.9 release candidate.

I tried using 'forks' instead, which seems to solve the problem.

That's a pretty meaningless statement. It's like saying that taking the train cured your car's fuel consumption problem :)