On the first quetion, you have the reference right, and the copy of the original data element right, but I would avoid applying the concept of pointers in perl, since they do not exist; $ptr in your code is still a reference just as much as $ref is. IMO, that last element is simply another reference.

Memory is supposted to be freed once the variable is out of scope and there are no more references to that data element. So in your example above, while the memory that $ref points to will continue to live outside of sub a, %copy and $ptr will not. Now if you returned, say "return \%copy;", and assigned a variable that value in the main part of the program, %copy's data will remain around even though %copy itself is no longer defined in it's block, until that new variable is to go out of scope.

With my experience with mod_perl is that you improve performance by avoiding having those large arrays and hashes which are mutable in memory, and use some sort of 'disk paging' system, whether that be through flat files, a DB, or some other means. The only data that should be persistent in a mod_perl script in order to avoid untamed memory growth are static, unchanging variables. As you've got it, it seems that you're trying to copy a hash often enough, and that might be causing a memory growth. This definitely sounds like you've got handing references to your various copies of that hash, and thus increasing the memory space. Is copying the hash necessary? This is probably the first question to ask, as PSI::ESP tells me that there's probably a better way to do it. Also, unrelated, but I've found that the module Clone is better to do any necessary duplication of non-scalar values, as opposed to trying to coerce references to work that way, particularly when they get into nested structures.

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain