Old Quora post: D vs Go vs Rust by Andrei Alexandrescu

jmh530 john.michael.hall at gmail.com
Fri Jan 5 03:11:42 UTC 2018


On Friday, 5 January 2018 at 00:58:12 UTC, Ola Fosheim Grøstad 
wrote:
>
> But if D is going to have a GC and no special code-gen to back 
> it up then it becomes important to stratify/segment the memory 
> into regions where you know that pointers that cross boundaries 
> are limited to something known, so that you can scan less 
> during collection. Which is rather advanced, in the general 
> case, IMO. But a possibility if you impose some 
> restrictions/idioms on the programmer.

I think it's a good idea. It relates to an idea I had had in the 
past with all the discussion on precise GC. One of the problems 
(as I think someone else mentioned above) with creating a precise 
GC for D is that it allows all sorts of things with unions and 
pointer arithmetic. However, it seems like just about all the 
stuff that makes a precise GC difficult is disabled in @safe code 
(or at least assumed to be @safe if coming through a @trusted 
block). So you could have a @safe region that is precise and a 
@system region that is as it is now. From the current system, you 
would have to be able to do some kind of run-time reflection to 
know if the code is in a @safe block or not. The simplest 
implementation would begin by handling just the case where you 
allocate in a @safe block and the object is only referred to in 
safe blocks (that way you know it's always safe). And then you'd 
have to probably do something special for when point to @safe 
code from @system code.

It also occurs to me that you could have a region for 
(completely) const/immutable data (not sure if you need to do 
this as a subregion within a precise region), assuming the GC can 
get that information. Transitive const/immutable means that 
pointers to this data cannot modify it. GC strategies that 
normally require write barriers wouldn't need them here.


More information about the Digitalmars-d mailing list