On Sunday, 20 July 2014 at 08:41:16 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 17 Jul 2014 13:40, "w0rp via Digitalmars-d"
The key to making D's GC acceptable lies in two factors I
believe.
1. Improve the implementation enough so that you will only be
impacted by
GC in extermely low memory or real time environments.
2. Defer allocation more and more by using ranges and
algorithms more,
and trust that compiler optimisations will make these fast.
How about
1. Make it easier to select which GC you want to use at runtime
init.
2. Write an alternate GC aimed at different application uses
(ie: real-time)
Yes, Please!
Being able to specify an alternate memory manager at
compile-time, link-time and/or runtime would be most
advantageous, and probably put an end to the GC-phobia.
DIP46 [1] also proposes and interesting alternative to the GC by
creating regions at runtime.
And given the passion surrounding the GC in this community, if
runtime hooks and/or a suitable API for custom memory managers
were created and documented, it would invite participation and an
informal, highly competitive contest for the best GC would likely
ensue.
Mike
[1] http://wiki.dlang.org/DIP46
