[MUD-Dev] New Beginings

[Bruce Mitchener]

David B. Held wrote:

> I also reject the claim that they are "better at memory
> management".  GC != "better memory management".  In fact, RAII is
> very nearly optimal usage of memory in most cases, is easy to make
> exception-safe, and doesn't stall your application while the GC
> thread kicks in.  And if you really feel you need the crutch of
> GC, you can always use a GC lib in C++.  However, you can never
> use manual allocation in Java or most other GC langs, even if you
> know there are places where it would significantly improve
> performance (and something like a MUD is an app where you are
> quite likely to be able to identify such cases).

David,

I recommend reading this email from the bottom up, with the
exception of this line.

Some suggested reading on GC:

    * The GC FAQ:

        http://www.iecc.com/gclist/GC-faq.html

    * "Garbage Collection Can Be Faster Than Stack Allocation"

        http://citeseer.nj.nec.com/appel87garbage.html

    * A post by one of the MS people on GC vs refcounting:
 
      http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572

    * A good collection of papers about GC, including a survey
      of GC types:

        ftp://ftp.cs.utexas.edu/pub/garbage/

    * The Memory Management Reference:

        http://www.memorymanagement.org/

The discussion of how the Orbitz system used Lisp as given by Paul
Graham is interesting as well:

   http://www.paulgraham.com/carl.html

Some of the details of how they handled large amounts of data for
the system are especially interesting in this context:

     "4. Because we have about 2 gigs of static data we need rapid
     access to, we use C++ code to memory-map huge files containing
     pointerless C structs (of flights, fares, etc), and then access
     these from Common Lisp using foreign data accesses. A struct
     field access compiles into two or three instructions, so
     there's not really any performance. penalty for accessing C
     rather than Lisp objects. By doing this, we keep the Lisp
     garbage collector from seeing the data (to Lisp, each pointer
     to a C object is just a fixnum, though we do often temporarily
     wrap these pointers in Lisp objects to improve
     debuggability). Our Lisp images are therefore only about 250
     megs of "working" data structures and code.

Really, as has already been said in some previous replies, it comes
down to knowing your toolset, knowing what it is good at, and what
its weaknesses are.  There is no silver bullet and no perfect
solution for managing memory.  But GC surely isn't the curse that
you seem to think that it is. :)

If you're basing your comments on Java, then a lot of the above
reading should be interesting.  Collectors need not be inefficient
and even may be faster or product better runtime results than
manually invoking free().  (There are dangers with putting
everything or a lot of stuff on the stack as well rather than the
heap.  Not all machines/OSes support really large stacks.)
Incremental collectors can have a time limit imposed on them to
prevent them from exceeding a given amount of time to avoid halting
your process.  Generational collectors are another good thing.

Naive usage of malloc/free or new/delete can also cause large
performance issues. (Brad Roberts has eeked out some pretty amazing
performance improvements in parts of the Cold server by
restructuring code to avoid a lot of allocation/deallocation that
wasn't useful.)

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev