Once again you're missing the point.
Of course you can get a malloc/free implementation that performs
garbage collection, such as Boehm's conservative GC. But C garbage
collection and malloc/free memory fragmentation are quite different
things. You can still get heavily fragmented memory with a C garbage
collector - or even with traditional malloc/free with an ideal
free()ing scheme.
Java and C garbage collectors are not directly comparable. Java is
able to compact memory by copying it and adjusting the references
transparently such that no unusable memory gaps are left. This is
not possible in C due to its cavalier pointer casting and raw memory
manipulation. Successful C garbage collectors instead opt for
conservative GC leaving the memory at the same location.
(I am not aware of any precise C garbage collector that works with
multi-threaded code or runs in a comparable time to malloc/free.)
Nevermind that typical garbage collectors (Java or C) need 3 times
or more working memory as a typical malloc/free scheme in order
to achieve decent timings. If memory is tight and performance is
paramount, then garbage collection is not the answer.
--- John Stanton <[EMAIL PROTECTED]> wrote:
> You confused my point which is that your usual malloc/free definitely
> does no garbage collection. That does not mean that a C language
> program cannot perform garbage collection, just look at a Java run time
> package for an example.
>
> If you never execute a free your dynamic memory is essentially contiguous.
>
> Joe Wilson wrote:
> > --- John Stanton <[EMAIL PROTECTED]> wrote:
> >
> >>Malloc is a concept implemented in various ways, some more successful
> >>than others but all of them hidden from the programmer. Free tries to
> >>give back memory but as you can appreciate unless you use some garbage
> >>collection scheme with backwards pointers fragmentation and
> >>checkerboarding is very difficult to avoid.
> >
> >
> > You seem to be confusing the topics of malloc/free memory fragmentation
> > with C garbage collection - they are orthogonal concepts.
> >
> > C's free() has no power to free up any extra memory as active memory
> > must stay where it was allocated until freed or else you'll have
> > dangling pointers. A single call to free() typically releases only memory
> > allocated by a single malloc() call. If, as result of the free, there
> > happens to be block(s) of memory immediately before or after that
> > released memory then that entire memory region can be coalesced and
> > be made available as a larger block to future mallocs.
> >
> > If a C program employs perfect 1:1 malloc'ing to free'ing, i.e., has no
> > memory leaks, then garbage collection is irrelevant to the topic of
> > memory fragmentation. It's not like C can employ a copying garbage
> > collector that moves memory blocks after free() without the knowledge
> > or participation of the host program. The malloc() call is where
> > fragmentation happens. Fragmentation in malloc depends on your allocation
> > strategy: first-fit, best-fit, short-lived versus long-lived pools,
> > per-allocation-size pools, statistical prediction, etc. Malloc must
> > try to guess where an allocation must go to try to prevent future
> > memory fragmentation.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
