Re: RAD vs. performance


"Marco van de Voort" <marcov@xxxxxxxx> wrote in message
news:slrnea9qnt.1s8b.marcov@xxxxxxxxxxxxxxxxx
On 2006-06-29, Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx> wrote:
Marco van de Voort <marcov@xxxxxxxx> writes:

We were only talking about deallocate, which is adding the block to
a freelist. A couple of pointer ops. (memblock pointer to global
freelist, global freelist pointer to the block, ready)

It's not that simple: objects have varying sizes, so blocks need to be
split and joined.

If the GC is allowed to postpone work, why isn't this allowed in C++ ? I
know it is not common, but most allocators _are_ pluggable, and it is even
not that uncommon to write a custom one if you are encountering problmes.


I guess one could write a replacement allocator, free of the horrors of
linked list memory management...


Do the merging explicitely in an onidle event if you have to.

typically, the gc doesn't postpone the work, rather, it gets out of doing it
at all...


I assume any language will have to do something if a reference goes
out of scope.

This is not true. There are garbage collectors which find live objects
instead of dead objects, move them elsewhere, and free the whole
memory block at once.

This includes OCaml's GC. The amortized cost
of freeing an individual object is about zero; OTOH there are costs
associated with keeping objects live for a long time.

But for such stuff you have to have administration which objects are live.
Or do you copy them to the new generation on the first access?


more often, for copy collectors, it is actually a matter of graph tracing.
we step along a large graph of objects, copying anything that is still live,
and then we are done with it (anything left in the old area is simply
forgotten).

this is where roots come in. they point to any central parts of the object
graph (contexts, toplevel parts of various subsystems, ...), and from thier
point of view, anything that is reachable exists, and anything that isn't is
not.


for example, if a c++ compiler were to keep track of roots, likely canadites
(for static roots) would be any global variables that refer to objects, and
on the stack would be any variables that hold class references.


for a conservative collector (typically not a copy collector, as there are
"problems" in this case), a common approach is to assume that the entirety
of the data and bss segements consist of roots, so anything that is
potentially a pointer (points to some known object on heap) is used as a
root.
similar is done for the stacks in any known threads.

then, the object graph is steped along as before (a conservative collector
will often assume that the entirety of an object's contents consists
potentially of roots...).

a cost here is that conservative collectors are often somewhat slower than
precise ones, but do have a strong advantage in that they work fairly well
within the c/c++ framework (absent needing to do much of anything
particularly fancy with the code).

or such...


.

Relevant Pages