-nogc

[Denis Koroskin]

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)

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.

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?