Re: Thoughts on memory freeing

S James S Stapleton wrote:

In languages, you end up having 'garbage collecting' methods for
freeing memory, and the other kind (I don't know the term off the top
of my head, but it's seen in C/C++ and done by directly calling the
memory deallocation function).

One term you can use is manual memory management, as opposed to Garbage
Collection whose whole purpose is to automate the task of deallocation.

There's arguments as to which is better for a program, and a lot of
what I've seen points to the GC methods.

If your language supports GC and you can accept some of it's
shortcomings, then GC certainly frees you from what would otherwise be
tedious accounting and not directly related to the problem that the
program tries to solve.

If you are using a language
where GC is nontrivial, would it be advantage to have a memory
deallocation thread? By that I mean, rather than directly deallocate
(i.e. a free call), call something which will put the memory free'ing
on another thread (either by placing it on a to-be-deleted queue -
which would have delays due to locks/mutexes, or by running each
deallocation in it's own thread - which would have the thread creation
overhead).

You would be reimplementing a lot of the functionality of your
language's "free" routine by doing this, unless of course your language
is primitive enough to not provide them in the first place.

For some applications which have a complex pattern of allocation and
deallocation it might indeed benefit from a customised memory manager.
Such examples are quite common in many large programs. But I would
stick to the functionality provided by the language unless such need is
really felt, since a good memory allocator is no trivial task,
particularly with the advent of multi-threading.

Does anyone have any thoughts (or better yet, suggestions for good
reading, preferably of the dead-tree kind, that I could pick up at the
library) on this?

<http://search.barnesandnoble.com/Memory-as-a-Programming-Concept-in-C-and-C/
Frantisek-Franek/e/9780521520430/?itm=3>
<http://search.barnesandnoble.com/Garbage-Collection/Richard-Jones/e/
9780471941484/?itm=2>
<http://www.memorymanagement.org/>
<http://portal.acm.org/citation.cfm?id=582419.582421>
<http://g.oswego.edu/dl/html/malloc.html>
<http://www.hoard.org/>
<http://www.fourmilab.ch/bget/>

and

Section 2.5 in Knuth's Fundamental Algorithms.

Also various language specific books (for example The Standard C Library
by PJ Plauger and C Unleashed by Heathfield, Kirby et al for C) devote
sections to consider memory allocation for their languages.

.

Relevant Pages

  • Re: Simple question, err... I think
    ... One assumption is then that client code should leak memory. ... Given that there's no deallocation for these RB trees, ... a pointer to an invalid tree and it might segfault. ...
    (comp.programming)
  • Re: Clearing Page Deallocation Table on 997-400
    ... Clearing Page Deallocation Table on 997-400 ... The PDT is a little different than the memory ... PDT, if it does, you can ignore the rest of this message. ... To join/leave the list, search archives, change list settings, * ...
    (comp.sys.hp.mpe)
  • Re: Clearing Page Deallocation Table on 997-400
    ... Clearing Page Deallocation Table on 997-400 ... The PDT is a little different than the memory ... PDT, if it does, you can ignore the rest of this message. ...
    (comp.sys.hp.mpe)
  • Re: Thoughts on memory freeing
    ... but it's seen in C/C++ and done by directly calling the ... memory deallocation function). ... Collection whose whole purpose is to automate the task of deallocation. ... If your language supports GC and you can accept some of it's ...
    (comp.programming)
  • Re: OOP
    ... then compact the unused memory. ... you will also see that the memory allocation increases are much faster ... than the deallocation rate. ... reference counted memory management has a major ...
    (microsoft.public.vb.general.discussion)