GC implementation

[Andrew Fedoniouk]

"MicroWizard" <MicroWizard_member at pathlink.com> wrote in message 
news:dvi1va$mm4$1 at digitaldaemon.com...
> As far as I know the D GC can be replaced.
> There are many GC theories and I think most of them can not be corrupted 
> with
> garbage. (They handle with working sets, aging and so on.)
>
> The problem is not a problem IMHO
>
> Tamas Nagy
>

It seems that conservative mark-n-sweep GC is the only option for D
(I mean for default GC). Which is not bad in fact. It is simple and
compact in implementation.

GC as one of possible memory managers. In effective systems it is used
in cooperation with implicit memory managment.
And this what is extremely good in D - it allows to use best of both
worlds.

Speaking about server side.
In fact it should be no GC in common sense there.
Memory allocation in execution of some request shall be done in
memory pool. Such pool (raw memory chunk) can be dropped at the end
of request in the whole - without any dtors and the like.
Sort of Apache memory pools.

I think that D-on-the-server frameworks shall use this approach.
This will eliminate problem mentioned by Frank completely and will
 make D servers lightning fast.

Andrew.