This process isn't guaranteed. For a chunk of memory to be released it must be of sufficient size to be worth it (glibc puts a minimum allocation size somewhere in the megabyte range to trigger allocation of a releaseable segment) and it must be completely empty. If the allocation size is too small what'll happen is that a larger block will be allocated and parcelled out in pieces by the C library. This larger block will often (though not always) be releasable, but since it's been carved into a zillion little pieces it rarely will ever be completely unused and thus released. Some systems also place a minimum hold time of some sort on the chunks, and won't release them immediately in case space is needed, to save the time spent freeing and then reallocating the space.

Basically if you allocate 100M in one chunk, it'll get released back to the system when unused. If you allocate 100M in 100 byte chunks, it'll never get released.

There's not much you can do with the current perl 5 source to make this happen any differently. Perl already does the right thing, and its up to the system and runtime libraries to decide whether chunks should be released. Unfortunately interpreters are rather complex beasts and making things work differently is a non-trivial and counterintuitive process.

_________
broquaint

How about Win32? Can't I just call free()?

milkbone - perl/tk instant messaging - it's the only way to fly

Well, a cursory test of:

   main()
   {
       char *foo = (char *)malloc(1000000);
       getch();
       free(foo);
       getch()
   }
[download]

Examined in task manager would suggest not, of course this is highly unscientific and someone else might know different.

/J\

Using free(ptr) will just make available the memory pointed to by ptr in the process' memory pool, not to the OS at large. This memory freeing behaviour isn't Win32 specific, but applies to most modern OSes.
HTH

_________
broquaint

Perl already does.

Ask them to look at the other processes. If I look at my processes I see four IEXPLORERs with 10-15MB, SiteView (in-house tool for web automation) 15 MB, ProductTranslator 14MB, svchost 10MB, DLLHOST 10MB, inetinfo 9MB, MCSHIELD 9MB, etc. etc. etc. etc.

Maybe it would also help if you told them that a VB program as small as this:

Sub Main()
    MsgBox "Ahoj Jendo", vbInformation, "Greeting"
End Sub
[download]

In either case I think the best solution would be to disable the Task Manager for those users ;-)

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

I've tried this argument as well, pointing out that iexplore often consumes more memory than my app. mysqld consumes around 40MB; opera takes about 25MB. I personally don't see much of a problem with these figures, so I think I may just have to give up on these users. If they're not willing to recognize that 25MB _isn't that bad_ then forget them. :)

The other thing is that when I open new windows in my app (it's Tk-based) or perform certain actions, the memory increases slightly. I've personally never seen it go beyond 27MB, even after days of usage and hundreds of windows being opened. So I guess what I want to know is: is this indicative of a memory leak, or is it something I shouldn't worry about?

This project can be downloaded from the link in my sig if anyone feels the need to test it out.

Thanks for your answers, everyone!

Bill

---

milkbone - perl/tk instant messaging - it's the only way to fly

If you open and close the same window many times does the used memory keep growing? If not then there's no leak in that part. It's next to impossible to prove a program has no leaks (especialy in Perl), but if you run it for long and do not see a problem I don't think it's necessary to care much :-)

As someone (sorry don't remember who) has in his/her signature: Worry only about the things you have to implement.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

Bill,
I think it's fitting to mention when you say that 25Mb is not that bad that Milkbone (I'm assuming that's what you're talking about) is an instant messenger app. I remember before you re-tuned it, the memory usage was close to 100Mb. When I'd compare it to AIM/Yahoo/MSN, each of those used under 10Mb. And usually my AIM is only at about5-6Mb. Compared to that, the 25Mb footprint of Milkbone did seem like a lot.
<aside>Anyways, I hope things have been well. Sorry I haven't kept up with *Mercury*, maybe I'll look at it when I get back to school.</aside>

$will->code for @food or $$;