[DGD] Garbage collection...is it worth it?

Shentino shentino at gmail.com
Fri Jan 5 20:22:40 CET 2007


Basically it's mean to handle an object that, due to a bug, doesn't
get properly destructed.  Such as game objects that were never put
into the heirarchy, or ustates or user objects dangling around after
the connection goes away.

My garbage collector finds that the object's "owner" (environment,
user, or connection) is nil, nukes it, and then logs it as GC'ed, so
that the admins would be on notice of a leak somewhere involving that
object.  So the GC is a combination diagnostic and safety valve too.
I may even consider tagging objects with the program that created
them.

Scanning rate is proportional to a *fractional power of the number of
objects*.  So, it might take a minute to run through 100 objects, but
10 minutes for 10000.

Ideally, the rest of the mud will be busy enough to prevent GC'ing
from having an adverse affect on performance.  My GC steps slowly, in
fractions of a second, and the checks are fast.  About the only time
the GC will be drowning out the rest of the mud is if the GC is the
only thing running and the mud is idle...in which case performance
isn't that big of an issue.

My GC will also spike a bit if it finds garbage.  Useful for mopping
up the aftermath of a clone storm, accidental or otherwise, especially
since objregd keeps a circular list.

AFAIK, you can't handle memory usage as a resource because there's no
way for the Klib to actually enforce it.  Memory usage of an object,
swapped out or otherwise, can change in SO many ways that the Klib
won't be able to detect.

Creating a big fat tangle of arrays and mappings is only one way to do that.



More information about the DGD mailing list