Denis Koroskin wrote:
On Thu, 23 Apr 2009 15:08:43 +0400, bearophile
<bearophileh...@lycos.com> wrote:
Andrei Alexandrescu:
The possibility of using D without a garbage collector was always
looming and has been used to placate naysayers ("you can call
malloc if you want" etc.) but that opportunity has not been
realized in a seamless manner. As soon as you concatenate arrays,
add to a hash, or create an object, you will call into the GC.
One simple possible solution: -nogc is to write C-like programs,
with no automatic reference counting. It doesn't include the GC in
the final executable (making it much smaller) and in such programs
AAs and array concatenation and closures are forbidden (compilation
error if you try to use them). "New" allocates using the C heap,
and you have to use "delete" manually for each of them. This is
simple. While adding a second memory management system,
ref-counted, looks like an increase of complexity for both the
compiler and the programmers.
Same here. My version of -nogc would work as follows:
1) You mark a module as -nogc/realtime/whatever (similar to
module(system) or module(safe)).
module(nogc) some.module.that.doesnt.use.gc;
2) Array concatenations are not allowed, array.length is readonly,
can't insert into AA, can't new objects (only malloc? this needs
additional thoughts)
I don't understand the appeal of this. I mean that means you'd have to
write your own Array class to do anything about arrays anyway. So why
not actually integrate it with the language?
3) ...
I believe this is an interesting way to explore. When one writes
real-time/kernel-level/etc code that shouldn't leak, he should be
very cautious and compiler should help him by restricting access to
methods that potentially/certainly leak. But how would one ensure
that?
A simple idea would be to allow module(nogc) only access other
modules that are marked as nogc, too. This will effectively disallow
most (or all - at least in the beginning) parts of Phobos (for a
reason!).
But marking whole module as nogc is not very good. For example, I'd
like to be able to read from and write to an existing array, but I
should be unable to resize them.
I think marking the entire application as gc or not is the most sensible
option. It's also relatively simple to implement.
Thus, all the method of Array but a void Array.resize(size_t newSize)
must be marked as safe/noleak/nogc/whatever (nogc is a good name
here).
Similarly, safe modules should be able to access other safe methods,
to, and T* Array!(T).ptr() should not be among them.
Thoughts?
My ambition about mixing together gc and no-gc modules is smaller. In
essence, I think C++ has shown that that's not an easy option. I want to
have the opportunity to choose at application level whether I will be
using gc or not.
In my opinion, anything that gets into defining new qualifiers or
storage classes is bound to cause too much aggravation. We already have
enough of those.
Andrei
