Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » unset, memory_limit »

unset, memory_limit

php.internals

Pierre-Alain Joye

22 years ago
Hello, While reading the bugs reports I came up with something I did not expect with the bug 27714. Maybe I have had too much ram in the past years ;) So this is bug is bogus, and this is the expected behavior. Unset (or set the var null) frees the memory only if memory_limit is enabled and not equal to -1 (unlimited) for both php5 and php4. Why? That's sound a bit silly to me, as that makes the related functions useless and does not allow anyone to free a huge variable when he does not need it anymore. My main problem is when I use CLI or gtk scripts. Or is there any "performance" issues there? At least it's a documentation bug as nothing in the manual described this behavior. pierre

Derick Rethans

22 years ago
On Mon, 9 Feb 2004, Pierre-Alain Joye wrote:
> Hello, > > While reading the bugs reports I came up with something I did not > expect with the bug 27714. Maybe I have had too much ram in the past > years ;) > > So this is bug is bogus, and this is the expected behavior. Unset > (or set the var null) frees the memory only if memory_limit is enabled > and not equal to -1 (unlimited) for both php5 and php4.
memory_limit has nothing to with the real memory usage. m_l only is internal emalloc'ed and efree'd memory.
> Why? That's sound a bit silly to me, as that makes the related > functions useless and does not allow anyone to free a huge variable > when he does not need it anymore. My main problem is when I use CLI or > gtk scripts. > > Or is there any "performance" issues there?
I think it's a default unix thing actually :) Derick

Pierre-Alain Joye

22 years ago
On Mon, 9 Feb 2004 15:14:46 +0100 (CET) Derick Rethans <derick@php.net> wrote:
> > So this is bug is bogus, and this is the expected behavior. Unset > > (or set the var null) frees the memory only if memory_limit is > > enabled and not equal to -1 (unlimited) for both php5 and php4. > > memory_limit has nothing to with the real memory usage. m_l only is > internal emalloc'ed and efree'd memory.
Not sure if I got the idea ;). If compiled with m_l, unset frees the var and the mem. If not, the mem is still allocated. Btw I was wrong, memory_limit set to -1 works too.
> > Or is there any "performance" issues there? > > I think it's a default unix thing actually :)
Hmm, I'm missing something here. If I understand this is due to my poor linux if I can't free the mem in my php script? :) but only if I use the memory_limit option. pierre

Jani Taskinen

22 years ago
On Mon, 9 Feb 2004, Pierre-Alain Joye wrote:
>On Mon, 9 Feb 2004 15:14:46 +0100 (CET) >Derick Rethans <derick@php.net> wrote: > >> > So this is bug is bogus, and this is the expected behavior. Unset >> > (or set the var null) frees the memory only if memory_limit is >> > enabled and not equal to -1 (unlimited) for both php5 and php4. >> >> memory_limit has nothing to with the real memory usage. m_l only is >> internal emalloc'ed and efree'd memory. > >Not sure if I got the idea ;). If compiled with m_l, unset frees the var >and the mem. If not, the mem is still allocated. Btw I was wrong, >memory_limit set to -1 works too.
Dunno about that..
>> > Or is there any "performance" issues there? >> >> I think it's a default unix thing actually :) > >Hmm, I'm missing something here. If I understand this is due to my >poor linux if I can't free the mem in my php script? :) but only if >I use the memory_limit option.
I think Derick meant that free(3) doesn't actually "free" the memory outside the process. It does become free for the running process. Or something like that. :) --Jani