[SDL] [SDL/C++] Garbage Collection

[Paulo Pinto]

Hi,

I hear a lot of developers saying that they manage memory better than any
GC. That might be true, but not on many real life situations.

First many last generation GC systems are able to allocate memory faster
than any *standard* C/C++ memory allocator that comes with
your compiler of choice. If you use a highly customized memory allocator
that is another matter.

Second it is very easy to misuse memory pools, if you don't plan correctly
their usage pattern.

Programming with GC enabled language is different than a non GC one, if you
use the same patterns you end up stressing the GC and blaming
the GC for your actions.

And note that many research OS have been done, where the GC is already
builtin, they don't support any direct memory managment besides the
device driver level.

For example, on the IT area where I work, telecomunications, languages with
manual memory management are now a realm of legacy applications,
or targeting hardware with memory constraints like embed systems with
microcontrolers.

But I agree with Julien, you have to know your problem at hand, weight the
plus and minus for each solution and take the best fit.

--
Paulo

On Wed, Jan 28, 2009 at 10:17 AM, julien CLEMENT <clementj2005 at yahoo.fr>wrote:

> First, a garbage collector has to guess what is the memory structure of
> your program (if I may put it this way). So, it is not optimal, and the only
> person who is supposed to know the best how memory is managed is you, the
> coder.
> So why relying on a third party component ? Because people become lazy I
> think :) To link with those old hardwares we were talking about, developers
> were able to produce amazingly robust softwares in pure assembler. I know,
> it's not really comparable with our modern applications involving a lot of
> heterogeneous components, I admit.
> It is just to emphasize the fact that GC can be helpful in some cases, but
> is just another tool having a *particular context of use* (just like
> pointers !)
> This context of use can be educational for instance, trying to learn
> algorithmic to some people without discouraging them with memory
> considerations. Others may list a lot of possible context of uses of a GC,
> I'm not to list them.
>
> A memory management technic that has not been mentioned (except if I read
> the emails too fast, maybe I did), is memory pools. A memory pool keeps
> track of every allocated memory areas in a centralized manner. You may
> attach a specific destructor function to each memory area, so that
> everything gets clear at once at some point of the execution (mostly at the
> end).
> The advantage of that is that a memory pool avoids memory leaks, and in a
> game, it ensures that there is no in-game memory free (which may cause lags
> if during action).
>
> Smart pointers or Shared pointers can have 2 policies: either there is a
> "owner" of a memory area, either the memory area is reference counted (There
> may be other strategies, I'm interested in knowing them if any). Just like
> GC, those tools have a specific context of use, it is not a machine for
> preparing coffee, and developers must make the effort to *understand* how
> they work, just like you have to understand how a screwdriver works.
>
> My conclusion is, many situations, many memory management solutions. In any
> case, you have to understand the limitations and the underlying mechanism.
> Software development is like clock-making, it is not magic.
>
> Julien
>
>
> --- En date de : *Mer 28.1.09, Paulo Pinto <pjmlp at progtools.org>* a
> écrit :
>
> De: Paulo Pinto <pjmlp at progtools.org>
> Objet: Re: [SDL] [SDL/C++] Garbage Collection
> À: "A list for developers using the SDL library. (includes SDL-announce)" <
> sdl at lists.libsdl.org>
> Date: Mercredi 28 Janvier 2009, 9h05
>
>
> And what is worse, very compiler specific.
>
> On Wed, Jan 28, 2009 at 6:39 AM, Pierre Phaneuf <pphaneuf at gmail.com>wrote:
>
>> On Tue, Jan 27, 2009 at 11:23 PM, Donny Viszneki
>> <donny.viszneki at gmail.com> wrote:
>>
>> >> It *is* possible to put that reference in a new
>> >> object, but it would be bad form (just like you can make C++
>> >> references be NULL, but it's reasonable to say "hey, don't do that,
>> >> it's evil!").
>> >
>> > I once wrote a class whose members lied in sub-fields of "this" cast
>> > as an address-sized union. This way I could create 2^32 instances of
>> > the class without allocating any memory. This only worked because the
>> > instances are all immutable and only existed as a programming
>> > abstraction using CPP macros. (Why not just use macros and leave C++
>> > classes out of it? I wanted the member methods to be compiled once,
>> > and I wanted my program to actually enter those methods, I did not
>> > want them inlined.. not all of them anyhow!)
>>
>> Perfect example.
>>
>> Don't do that, it's evil! :-)
>>
>> --
>> http://pphaneuf.livejournal.com/
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090128/ec82516e/attachment.htm>