Leak Tolerances

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding
View previous topic :: View next topic  
Author Message
Auroness



Joined: 22 Sep 2005
Posts: 3

PostPosted: Tue Mar 28, 2006 1:30 pm    Post subject: Leak Tolerances Reply with quote

I am currently working on plugging leaks in my MUD engine, and I am wondering how much tolerance other coders have for leaks and how do you deal with the ones that do exist? I am using a DIKU variant, written in C and I have read that DIKUs "just leak". It is inherent in the orginal code. Personally, I am trying to plug as many of the leaks as I can find, but I know that some will slip past and others are just beyond my abilities to repair. When the memory useage gets too bad, the server can be rebooted, but I am trying to keep that from being a common occurence.

So my question for others in this forum is how much is acceptable? When you do have memory problems, how do you deal with it? "Not my fault. We need a bigger server", "Game is closed, come back in an hour", or "My game isn't big enough to generate leaks"
Back to top
View user's profile Send private message
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Tue Mar 28, 2006 6:15 pm    Post subject: Reply with quote

You can fix the leaks in a DIKU. Sloth is DIKU-derived, and it doesn't leak much. At some periods in its history it has leaked more, and then we had scheduled automatic reboots. Our players found that daily reboots were mildly annoying, while every-three-days reboots were not such a problem.

To minimize the pain you can schedule the reboots to occur automatically at an hour when there are relatively fewer people logged on, you can put safety checks around them to make sure people don't ever lose anything because of a scheduled reboot, and you can automatically issue warning messages at some intervals before a reboot.

Valgrind is a good tool for finding leaks. It's also very helpful to make a stripped-down version of the data files with just a few rooms, a few mobs, etc., so that valgrind runs faster and produces more manageable amounts of output.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Tue Mar 28, 2006 10:46 pm    Post subject: Reply with quote

Depends on the coder/admins, I think. I am pretty opposed to any leaks and wrote a memory tracking class as a result; that'll tell me where the memory was allocated for 'leaked' memory. Each to their own though...if I'm losing 50kb / day of memory, it isn't a priority.
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Tue Mar 28, 2006 10:55 pm    Post subject: Re: Leak Tolerances Reply with quote

Auroness wrote:
I am using a DIKU variant, written in C and I have read that DIKUs "just leak". It is inherent in the orginal code.


A lot of those leaks aren't really leaks, but memory recycling. Instead of throwing away the unneeded chunk of memory, the mud will sometimes hold on to it so that it can be reused next time.
Back to top
View user's profile Send private message Visit poster's website
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Wed Mar 29, 2006 11:11 pm    Post subject: Reply with quote

I treat memory leaks like any other bug, which is to say that I fix as many as I can. =)

KaVir wrote:
A lot of those leaks aren't really leaks, but memory recycling. Instead of throwing away the unneeded chunk of memory, the mud will sometimes hold on to it so that it can be reused next time.


That memory recycling code can be safely removed, however - modern malloc implementations do the same sort of things internally (binning) so there's not much advantage to replicating it yourself in most cases.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kaz



Joined: 05 Jun 2005
Posts: 24
Location: Hampshire, UK

PostPosted: Thu Mar 30, 2006 12:59 pm    Post subject: Reply with quote

Memory leaks should be hunted down and destroyed. But don't confuse an ever-growing memory footprint with a memory leak. In Dikus, as stated, memory is recycled and not freed. This means that the memory footprint never shrinks. However, as long as memory is used in a consistent manner, all memory that has been allocated is reachable, and can be reused.

In my Vision codebase, I do two thinks to avoid memory leaks. First, my C++ code uses RAII objects exclusively for handling pointers (I see boost::shared_ptr<> in my dreams, now). This doesn't completely elide the problem, but it rules out a complete category of memory leaks. It's only cyclic references I have to watch for now.

The second is that I've implemented my scripting language to run in a runtime where two of the three data types, Object and String, are internally reference counted (and the scripting language itself has no way of manipulating these reference counts). Again, I have to be careful of cyclic references, but I intend to implement a garbage collector that looks for unreachable objects and strings at a later date.
Back to top
View user's profile Send private message
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Fri Mar 31, 2006 6:23 pm    Post subject: Reply with quote

Leaks are a Bad Thing. One of the reasons I like programming in a language that's a bit less archaic than C or C++ is that you can completely forget about memory management about 97% of the time. Saves a lot of unnecessary faffing about and lets you get on with useful programming.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign