Garbage collector

[renox]

FlyTox wrote:
> Coming from C++, I'm not a big fan of Garbage Collection which I 
> consider as an open door to poor program design.

Some C++ program such as Mozilla/FF suck at memory handling too, GC is
not a magic wand, it's just easier and you can still do manual
allocation if you want.

[cut]
> As far as I understand, the gc is part of the language and will be 
> nested in the compiled EXE. This basically means that the allocated 
> memory will always expand till gc decides it should collect garbage
> (or when the user calls a xxxxCollect() function). This means that
> the D application will work well... to the detriment of all other
> tasks!

Depends of memory usage of course.
But this means also that in some case, the GC can have higher
performance than malloc/free as it frees several objects at the same
time (with the price to pay of a bigger pause during the collection
which may or may not be a problem for the application, of course some GC
avoid the pause but have lower performance.)

[cut]
> Could we have the D GC as a shared lib among all D apps?

No, because of memory protection as other have pointed.

> Can we have some kind of GC tuning like "do not use more than x
> amount of memory" or at least have an idea of what the gc could free
> in order to decide when to call a xxxxxCollect function? Looks like
> we're out of control on GC, aren't we?
Some GC for Java has such knobs but it's quite annoying to have to
handtune the GC memory usage.

There has been some research (see the PageLevel Cooperative Garbage
Collection paper) to have the GC cooperate with the virtual memory 
manager of the OS to avoid having the GC overflow the available memory 
size which would create swapping problem.
The big downside of course is that the kernel must be modified to
support this but for Linux or *BSD this is not so far fetched, if for 
example Parrot or Harmony implement these kind of GC in the future..

Regards,
RenoX