in reply to Re^2: Massive Perl Memory Leak
in thread Massive Perl Memory Leak

If %branchdata contains references to hashes or arrays, then doing a shallow copy into a key of %datahash will result in the sharing (not in the threads::shared sense!) of the referenced data between the two structures. Eg.

%a = ( 1, {a=>b=>c=>d=>}, 2 =>[ 1..5 ] );; %{ $b{ copy } } = %a;; print Dumper \%a, \%b;; $VAR1 = { '1' => { 'c' => 'd', 'a' => 'b' }, '2' => [ 1, 2, 3, 4, 5 ] }; $VAR2 = { 'copy' => { '1' => $VAR1->{'1'}, '2' => $VAR1->{'2'} } };

To deep copy compound structures, you need to use Clone or (as someone else advised earlier) Storable::dclone().

But whether that has anything to do with your memory growth is impossible to tell from the code shown. If both of these structures are lexical and being garbage collected, then that (shallow copying) should not be the cause the symptoms you are describing.

It sounds like you may be creating some kind of a circular reference somewhere. This could cause the kind of accelerating memory growth you mention. Maybe. But again, it's just guesswork without seeing the code.

And the problem does not seem to be related to your use of threads. Though it is obviously exaggerated by there being 100 times as many 'programs' all doing the same bad thing--whatever that is.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^4: Massive Perl Memory Leak
by wagnerc (Sexton) on Jun 12, 2007 at 21:16 UTC
    Right now I'm reverting to rebuilding the script block by block from the old version that doesn't spiral out of control. Now that version's no slouch either. It grows a good bit but it stays reasonable by Perl standards. Say 33% growth from start to completion. Most of the code is the same, and is of the same type, but whatever changed, changed the mem growth to 400%.

    Speaking of garbage collection, is there any way to look into Perl to see just what when and where things are garbage collected? I've had, and still have, this suspicion that Perl is just not garbage collecting the way it should.

      Speaking of garbage collection, is there any way to look into Perl to see just what when and where things are garbage collected?

      You can use Devel::Peek on a variable and check that its ref count is what you expect.

      I've had, and still have, this suspicion that Perl is just not garbage collecting the way it should.

      The likelihood that such a thing has hidden for thirteen years seems low, to me.

        If it were single threaded, yes. But remember threading is still Wild West territory and Perl has never been particularly concerned with memory stingyness. I can just imagine a situation where threads don't know who's supposed to be doing what with the process heap.

        The problem with checking reference counts and similar modules is that u have to know what variable ahead of time to check. If data is in a state where it "should" be garbage collected, then there's nothing to check a ref count of. When variables die Perl only guarantees that the varname is no longer accessible, not that anything in particular has been done with the SV's behind the scenes. In fact the whole Perl memory management philosophy seems too lacidasical. That doesn't work anymore when u have a massively parallel script running for a day and a half. :)