On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote:
Walter Bright:
It isn't off-topic at all. It's very relevant to D.
I also agree with what he says about GC.
There's a long way from recognizing those problems, to having
good enough solutions in D.
Some possible attack strategies for D are:
- A less allocating Phobos to produce a bit less garbage;
- A more precise GC to avoid some memory leaks;
- Perhaps an annotation to disallow heap allocations in a
function or a piece of code;
- Some good way to allocate variable length arrays on the stack
(http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some
arrays produce no garbage);
- The implementation of "scope" maybe helps a bit;
- Multiple alias this opens some opportunities to use structs
in more places, avoiding some heap allocations.
- Currently Phobos Scoped/emplace are not very good.
Is that enough? Rust language designers seem to think that's
not enough. Opinions are welcome.
Bye,
bearophile
I agree.
Additionally I think it might be worthwhile to also have a look
at other system languages with GC.
The ones I had some contact with:
- Oberon, Oberon-2, Oberon-7, Component Pascal, Active Oberon
(Basically Oberon Family)
- Modula-3
- Sing# (C# 2.0 with extensions for Singularity)
The main problem is that they failed to enter the industry, as
such for some of them (Modula-3) it is very hard to get proper
information nowadays.
In the Oberon family for example, GC only works when New or
string manipulations are involved. The rest of memory is the
usual static allocation at compile time or VLA arrays as
bearophile mentions.
Both Modula-3 and Active Oberon allow for the declaration of
untraced pointers, which boils down to manual memory management
with compiler help.
In all of them it is also possible to circumvent the type system
and do manual memory management via the SYSTEM package/unsafe
constructs. Although it is seen as something to do with expert
hat on and big red alert. :)
--
Paulo
