Date: Fri, 07 Aug 1998 12:11:01 +0200 From: Stefan Eggers <seggers@semyam.dinoco.de> To: Bruce Evans <bde@zeta.org.au> Cc: syko@sykotik.org, dg@root.com, freebsd-current@FreeBSD.ORG, freebsd@xaa.iae.nl, narvi@haldjas.folklore.ee, seggers@semyam.dinoco.de Subject: Re: memory leaks in libc Message-ID: <199808071011.MAA03715@semyam.dinoco.de> In-Reply-To: Your message of "Fri, 07 Aug 1998 02:36:07 %2B1000." <199808061636.CAA00012@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > The env functions are already costly. They use dumb linear searches > and malloc(), and don't alloc a little more than necessary so that the > environment can grow a little without reallocation. Garbage collection Maybe the ideal solution would be to put the variables one encounters on a linear search into a more convenient data structure like a tree for later references and on subsequent getenv's one first checks in the tree for the variable and if it is not there starts from the point where the last linear search ended. If we brought over all variables we only consult the tree. Settings by setenv get put into the tree right away. To get the memory leak fixed each node entry contains a boolean which indicates the origin of the string, i.e. false for those we got from the list and true for those we malloced. For convenient subprocess creation where one needs an array of poin- ters to the environment variable settings one could have a parallel array of pointers and put an index into this array in the nodes. Then one can easily update this array while one manipulates the node. Does that sound reasonable? It would make frequent requests for the same variable fast and fixes the memory leak. The disadvantage is the time penalty for a variable lookup where the variable is not already in the tree and that we need a little bit more memory for the nodes. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808071011.MAA03715>