in reply to Re: Postpone garbage collection during a child process run?
in thread Postpone garbage collection during a child process run?

Let me add some information to help the PerlMonks help me.

Why do I think it has something to do with garbage collection?

Since the use of the hash pointer did not cause a 'die', it must be still pointing at valid allocated memory. And when looking at the syslog entries, the pointer address at start of the subroutine and at the end of the routine is the same, as well as where it's pointing. However, after the return from the subroutine, the syslog entries show that the pointer address is the same, but it's contents (where it is pointing) is different, and that address points to the valid hash but without the changes made during the call to the subroutine. This looks like the hash was copied to a new location, and the old hash memory was placed on a free list, and not returned to the operating system.

I can only guess about this!

It seems, I was able to use the pointer before the copy completed, or some other type of race condition existed between garbage collection and my program. If garbage collection locked the hash, then the pointer wasn't updated until after I used it or when the subroutine returned ( since it looked like the subroutine was never called ).

If I am using the term 'garbage collection' incorrectly and a different term defines what I observed, please enlighten me.

Thank you

"Well done is better than well said." - Benjamin Franklin

  • Comment on Re^2: Postpone garbage collection during a child process run?

Replies are listed 'Best First'.
Re^3: Postpone garbage collection during a child process run?
by Corion (Patriarch) on Oct 06, 2010 at 18:57 UTC

    What you describe is not what happens. You have a subroutine which triggers some action at a distance, namely, cleaning out a hash. You also seem to be quite confused when talking about references and what they reference, as you name them "pointers" and talk about "addresses". If you mean by "address" what you get when you print a reference (HASH(DEADBEEF)), then that is somewhat like a memory address, but you're better off treating it as a unique number identifying this particular hash.

    Perl has no processes running asynchronously to your program. There is no "garbage collection" process, and memory allocated to Perl data structures is only released when there is nothing more (in Perl space) referencing it. So you have a logic error in your program that has nothing to do with memory management at that level.

    Now, what could help us help you better was if you can show the relevant code that cleans out the hash contents and how you call it. Maybe it is something like this:

    sub foo { my %some_hash = @_; }; foo( %another_hash );

    Here, changes to %some_hash will never show up in %another_hash.

    But maybe you are passing around nested references like this:

    sub foo { my %some_hash = @_; }; my %another_hash = ( a_deeper_hash => { a => 1, }, another_deeper_hash => { b => 2, }, ); foo( %another_hash );

    Now, changes made to $some_hash{ a_deeper_hash } will change $another_hash{ a_deeper_hash }, as the copy of the hash is a shallow copy.

    My advice is this vague because you steadfastly refuse to show even what you see, the concrete debug messages and the code producing them, not to mention the code relevant to this. I understand that it's a tough task to remove more and more parts from a program that fails from time to time until you get to the input that makes it fail, but the only approach I know to accomplish is to reduce the input data until you find a dataset that always triggers the behaviour and then to start removing parts of the code, keeping only those parts that reproduce the error.

    A reply falls below the community's threshold of quality. You may see it by logging in.