On Tuesday, 4 February 2014 at 12:18:22 UTC, ed wrote:
On Tuesday, 4 February 2014 at 12:03:31 UTC, Frustrated wrote:
[snip]
It would be nice if one could simply write some allocator, drop
it into D, and everything work out dandy. e.g., I want to try
out
a new super fast AGC like metronome GC, I write the code for
it,
tell D to use it, and then reap the benefits.
You can write your own GC now and drop it in, we did as an
experiment.
If you're talking about a dropping in an allocator that is
another matter, an allocator is not a GC.
Cheers,
ed
Yes, you can do a lot with D, even rewrite D runtime to remove GC
dependent stuff, or write your own Phobos library. It is not easy
and D is not *designed* to do that.
AGC is about automatic deallocation so you don't have to *free*
the memory you allocate. To do this you have to allocate through
the GC so it knows when you allocate. So a GC is an allocator.
Regardless, I would simply like to have, as I'm sure many would,
the ability to set how D handles memory.
1. No memory management at all - Fast as possible. No memory is
ever free'ed. Similar to how DMD works.
2. Manual memory management - Pretty fast but old school.
Predictable but error prone. Different allocating schemes for
dealing with efficiency. Some apps require this to be performant.
3. Automatic memory management - Easy to use = Lazy mentality.
Safer. Most apps would not need anything more than this.
4. Combination of the above - The hard part. How to make all this
stuff plug and play, work well together, easy to use, etc...
Right now, D basically only has #3. Some have worked D to use 2.
std.allocators goes a long way in the right direction as does
std.allocators.gc. All I'm wanting is a unified way to use it all
and to get D and phobos off the hard dependence of the GC.
