Just to expand on what Michael said about memory pooling, and to expand on why the memory usage doesn't go down any when memory was being freed... if you look at those free_* functions in recycle.c, as well as the new_* functions in there, you'll notice that after all of the strings and whatnot are freed within the free_* function, and the structure itself is them emptied out, the structure is tacked onto the end of a linked list that just keeps track of all of the free chunks of memory allocated for that particular type of structure (char_data, pc_data, etc)... when the new_* function is called, it first checks to see if there's anything available in that linked list, and if so, it pops one structure off of that list to use for that particular call... if that list is empty, it allocates a new block of memory for it... I was always told that doing so was also faster than allocating a new chunk of memory for the structure, and I'm not sure if that's true or not, but it would seem to me that it is, and that's the meaning of recycle.c, is that it recycles all of those already-used blocks to be allocated again instead of calling for new memory...
Richard Lindsey. -----Original Message----- From: Michael Barton [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 11:53 PM To: [email protected] Subject: Re: Memory Questions. alloc_perm should mostly used to allocate structures that have their own free_ and new_ calls (i.e. stuff in recycle.c) and things that are never deallocated (i.e. rooms, mob indexes, obj indexes...). Each data type that's handled in recycle.c has its own memory pool (usually *_free). So memory you allocate with alloc_perm should never be sent to free_mem, it should be permanent or have a specialized memory pool. alloc_mem and free_mem on the other hand use a generic memory pool and are mostly used to allocate memory for strings. str_dup and free_string are basically just wrappers for alloc_mem and free_mem that allocate and deallocate based on the string's length. free_string and free_mem won't make memory usage go down because memory is never freed once it's allocated, it just gets put back in the general pool. Normally what'll happen is the mud will allocate new memory like crazy for a while after it starts up. Once all of its pools are full, it won't allocate any more. In my experience, memory leaks almost always have to do with strings. For example, in stock Rom there's a potential problem with char_data->material not being free_string'ed by free_char in recycle.c. So potentially every time a char_data is freed, you lose the block of memory that's pointed to by material. So I usually start by looking at all of the char * variables in the structures and make sure they get freed when the structure is. On 1/23/06, Valnir <[EMAIL PROTECTED]> wrote: > Ok, here's a question for you that will probably just make some of you laugh > at me, but I don't care. I need someone to PLEASE explain to me what the > difference is between alloc_perm and alloc_mem in ROM 2.4b6.. I have a slow > memory leak (other day it's not so slow) that makes the perm blocks and > bytes (sAllocPerm and nAllowPerm) steadily increase. The physical RAM usage > obviously goes of with them. If someone can please explain to me the > difference and where each should be used I would be very grateful. If you're > feeling really helpful, maybe you can even explain why free_string and > free_mem don't make it go back down any. > > Any help here is very appreciated. > > Thanks! > > - Valnir > > > > -- > ROM mailing list > [email protected] > Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom > -- ROM mailing list [email protected] Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom -- ROM mailing list [email protected] Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom
