I also noted that arrays in Pike can share their content. /.../
What you're seeing is that strings are shared; there's only one instance of every unique string in a pike process. That's why e.g. indexing mappings with strings is so fast.
I also have another question. Why not taking an already existing garbage collector (for example http://www.hpl.hp.com/personal/Hans_Boehm/gc/) and adapt it to Pike ?
There's a tight integration between the gc and the data types in Pike, so I suspect adapting an existing one would essentially mean rewriting it.
The one you pointed out scans through the memory looking for patterns that can be references to or into allocated blocks. Very convenient, but it means it can keep blocks around too long just because there are values that happen to look like pointers, and it also means quite a bit more work scanning the blocks during gc. The one in Pike can do better since it knows where the pointers are.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-06-11 23:40: Subject: Re: Debugging memory problems
Hello,
Is it enough to set those variables to 0 ?
Depends on what you want to accomplish. If you want to avoid garbage that's left around until the next gc then you only need to zero variables if their values directly or indirectly refers to the object they're in. Normal acyclic structures are freed as soon as possible through reference counting.
Ok. Thank you for the help :)
. When I call destruct(), destroy() is sometimes not called after some time or after the user login again or if I reload the module.
I assume there's a "not" too much in that sentence. Seems like destroy is called by the gc or as a result of that the object runs out of references. Are you absolutely sure that you call destruct on the right object? I often put in some debug code like this to make sure I can tell objects apart:
This one was my fault, I did a destruct on the NULL value and didn't see it. It works now.
I also noted that arrays in Pike can share their content. For example if I fill 30MB in this arrays:
$ ps auxw|grep pike david 446 13.5 1.1 8784 4360 pts/4 S 23:25 0:00 pike
array memtest = ({ Stdio.File("/dev/zero", "r")->read(31457280) });
$ ps axuw|grep pike david 446 1.9 9.1 39632 35320 pts/4 S 23:25 0:01 pike
array memtest2 = ({ Stdio.File("/dev/zero", "r")->read(31457280) });
$ ps axuw|grep pike david 446 2.5 9.1 39632 35320 pts/4 S 23:25 0:01 pike
array memtest3 = ({ Stdio.File("/dev/zero", "r")->read(31457280) +
"kjshjkzerhzjkerhzkjer" }); $ ps axuw|grep pike david 446 1.6 17.0 70356 66044 pts/4 S 23:25 0:02 pike
That explains why I don't see the leak sometime. For example if I login as the same user again on the same computer (so I get the same session).
I also have another question. Why not taking an already existing garbage collector (for example http://www.hpl.hp.com/personal/Hans_Boehm/gc/) and adapt it to Pike ?
/ David Gourdelier
On Thu, 5 Jun 2003, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Hi,
Here are some more notes I have regarding this problem:
. It seems like empty array or string with the same content share the same references. That's why I got lot of references for the empty array. So I put something like ({ "ThisiSaRandDomString232323239084 "}) in every arrays of the objects and they are not referenced anymore. Is it enough to set those variables to 0 ? . _refs always report lot of references but _locate_references doesn't find them. For example I have lot of things like this for strings:
variable searchstring ("") is referenced 1044 times **Looking for references to 0x83773ec: **Done looking for references to 0x83773ec. variable defaultsentfolder ("") is referenced 1044 times **Looking for references to 0x83773ec: **Done looking for references to 0x83773ec.
Is it normal ?
. When I call destruct(), destroy() is sometimes not called after some time or after the user login again or if I reload the module.
/ David Gourdelier
Please ignore that; I missed the stop function.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-06-05 17:20: Subject: Re: Debugging memory problems
There's a reference back through sess->imapclient->session.
/ Martin Stjernholm, Roxen IS
-- David Gourdelier
/ Brevbäraren
-- David Gourdelier
/ Brevbäraren