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.
