-nogc

[Andrei Alexandrescu]

Denis Koroskin wrote:
> On Thu, 23 Apr 2009 15:08:43 +0400, bearophile
> <bearophileHUGS at 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