dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article 2. Maintaining two separate heaps (the manually memory managed C heap and the GC'd D heap) is a massive and completely unacceptable kludge because:
Coding in a way that requires the GC to offer manual deletion is a completely unacceptable kludge. Most GCs could NOT offer a primitive to manually release memory. Designing D around a requirement that manual deletions work on the GC is crippling pressure on GC designers.
1. If you just want to delete a few objects to make the GC run less often, you can just add delete statements for the common code paths, or paths where the end of an object's lifetime is obvious. You then just let the GC handle the less common code paths or cases where object lifetimes are non-trivial and gain tons of simplicity for only a small performance loss. If you have to handle all the odd code paths manually too, this is when bugs really start to seep in.
Many people's famous last void were "the end of an object's lifetime is obvious".
2. Heaps have overhead. Two heaps have twice the overhead.
Where did that come from?
3. addroot(), etc. is a PITA *and* adds yet another place where you have to lock on the GC mutex. Half the need for manual memory management in D is because the GC sometimes scales poorly to large numbers of threads. This would definitely not help the situation.
So right now do you have it for free? I don't understand. What are you comparing against what?
4. Using the C heap whenever you want the ability to manually free something doesn't play nicely w/ builtin language features such as classes, arrays, associative arrays, etc., or objects returned from library functions.
It shouldn't too.
Because of these 4 issues, I feel that only being allowed to do manual memory management if you use the C heap is such an unacceptably bad kludge that it is for many practical purposes akin to not being allowed to do manual memory management at all. This is unacceptable in a systems/performance language.
I completely disagree. I believe that "unifying" safe and unsafe styles under the same umbrella is an unacceptably bad kludge that is for many practical purposes akin to not being allowed to provide the slightest guarantee about any piece of D code. That's not where D should be going.
Remember, performance/systems languages can't place excessive emphasis on safety and absolutely MUST assume the programmer knows what he/she is doing. If you want Java, you know where to find it.
We agree on D being able to provide every bit of performance control needed. But my understanding you foster a programming style that's a hodge-podge of safe and unsafe coding under the same syntactic pretense. I don't think that's a good way to go.
Andrei
