What's the state of deterministic GC in D, or alternatively being
able to disable the GC?

I've been looking into languages to implement a real-time testing
system and had thought of D, but AFAICT the GC makes it
unsuitable.  The CGCD effort looks to be moving in the right
direction, but it would still be stop-the-world, just not for as
long as it used to.

Something like Lua's iterative GC would be better, as I think it
would give deterministic real-time latency alongside the GC (by
making the GC interruptible).  Are there any plans in this
direction?

Or is there now the possibility of disabling the GC altogether,
or replacing it with a refcounting 'GC' etc?

On Wed, 28 Jan 2015 06:58:41 +0000, Tom wrote:

> Or is there now the possibility of disabling the GC altogether, or replacing it with a refcounting 'GC' etc?

you still can do manual memory management with `malloc()` and friends. but you must be very cautious with dynamic arrays and slices. may be your best bet is to not use built-in dynamic arrays at all and write a replacement class with manual memory management. ah, and the same for AAs.

it's possible, if somewhat cumbersome. and you can use 'dmd -vgc' to check for hidden allocations. so it may be not as simple as adding some compiler switch, but still not that hard too.

http://dlang.org/phobos/core_memory.html#.GC.disable ?
Some people including myself write D with only minimal runtime (bare metal profile). Is it what you're looking for?

On Wednesday, 28 January 2015 at 06:58:42 UTC, Tom wrote:
>
> Or is there now the possibility of disabling the GC altogether,
> or replacing it with a refcounting 'GC' etc?

You can disable the GC:  http://dlang.org/phobos/core_memory.html#.GC.disable

There is a RefCounted struct in the standard library: http://dlang.org/phobos/std_typecons.html#.RefCounted
But, last I heard there were some problems with it:  http://forum.dlang.org/post/cakobtxrmvrpqhswmfsy@forum.dlang.org

I suggest reading this article: http://wiki.dlang.org/Memory_Management.  It provides more information and working examples illustrating some techniques for avoiding the garbage collector.

Note that D has 3 built-in types: exceptions, dynamic arrays, and associative arrays, that may be difficult to use without the GC:  http://dlang.org/builtin.html.

Mike

On Wednesday, 28 January 2015 at 07:43:35 UTC, ketmar wrote:
> On Wed, 28 Jan 2015 06:58:41 +0000, Tom wrote:
>
>> Or is there now the possibility of disabling the GC altogether, or
>> replacing it with a refcounting 'GC' etc?
>
> you still can do manual memory management with `malloc()` and friends.
> but you must be very cautious with dynamic arrays and slices. may be your
> best bet is to not use built-in dynamic arrays at all and write a
> replacement class with manual memory management. ah, and the same for AAs.

There is also bitbucket.org/infognition/dstuff for some other gc
related hacks that may be of use.

On 01/28/2015 09:12 AM, Mike wrote:
>
> Note that D has 3 built-in types: exceptions, dynamic arrays, and
> associative arrays, that may be difficult to use without the GC:
> http://dlang.org/builtin.html.

4 actually, if you count delegate closures.
http://dlang.org/function.html#closures

On Friday, 30 January 2015 at 11:54:54 UTC, Martin Nowak wrote:
> On 01/28/2015 09:12 AM, Mike wrote:
>>
>> Note that D has 3 built-in types: exceptions, dynamic arrays, and
>> associative arrays, that may be difficult to use without the GC:
>> http://dlang.org/builtin.html.
>
> 4 actually, if you count delegate closures.
> http://dlang.org/function.html#closures

My apologies for posting a question and then disappearing for eighteen months.  I thought it might be useful if I posted some feedback here.

We ended up going with Lua here.  The main point in favour was the iterative GC which can be interrupted and so can meet deterministic deadlines.

I was aware when I posted that it's possible to write D that doesn't use the garbage collector; however, since we want operators to be able to write bits of script that would get compiled and executed, we couldn't see any obvious way of presenting a 'safe' subset of the language; anything we did would either let them do things that would invoke the garbage collector (often in fairly unobvious ways) or enter code that would compile but fail to run (if we built the runtime without the GC).

Regards,
Tom

On Wednesday, 26 October 2016 at 16:15:19 UTC, Tom wrote:
> My apologies for posting a question and then disappearing for eighteen months.  I thought it might be useful if I posted some feedback here.
>
> We ended up going with Lua here.  The main point in favour was the iterative GC which can be interrupted and so can meet deterministic deadlines.
>
> I was aware when I posted that it's possible to write D that doesn't use the garbage collector; however, since we want operators to be able to write bits of script that would get compiled and executed, we couldn't see any obvious way of presenting a 'safe' subset of the language; anything we did would either let them do things that would invoke the garbage collector (often in fairly unobvious ways) or enter code that would compile but fail to run (if we built the runtime without the GC).
>
> Regards,
> Tom

Did @nogc not exist back then?

On Wednesday, 28 January 2015 at 07:43:35 UTC, ketmar wrote:
> On Wed, 28 Jan 2015 06:58:41 +0000, Tom wrote:
>
>> Or is there now the possibility of disabling the GC altogether, or replacing it with a refcounting 'GC' etc?
>
> you still can do manual memory management with `malloc()` and friends. but you must be very cautious with dynamic arrays and slices. may be your best bet is to not use built-in dynamic arrays at all and write a replacement class with manual memory management. ah, and the same for AAs.
>
> it's possible, if somewhat cumbersome. and you can use 'dmd -vgc' to check for hidden allocations. so it may be not as simple as adding some compiler switch, but still not that hard too.

For manually managed arrays, containers, I would recommend the emsicontainers (https://github.com/economicmodeling/containers)

On Wednesday, 28 January 2015 at 08:12:25 UTC, Mike wrote:
> On Wednesday, 28 January 2015 at 06:58:42 UTC, Tom wrote:
>>
>> Or is there now the possibility of disabling the GC altogether,
>> or replacing it with a refcounting 'GC' etc?
>
> You can disable the GC:  http://dlang.org/phobos/core_memory.html#.GC.disable
>


I think it's important to note that there is three ways to go to minimize GC impact, by order of increasing difficulty:

1. Minimize allocations andthe size of scanned heap. This allows to still use the GC which is handy. Stay at this level if you need only speed.

2. Not enabling the runtime. This forces you to be fully @nogc but using the GC is a runtime error instead of a link error. Stay at this level if you need reduced memory consumption.

3. Not link with the runtime, or link with a minimal runtime. This is the hardest way and yield smaller binary size of all, along with the speed and reduced memory consumption.

GC avoidance is a spectrum.