Precise GC state

[Jonathan M Davis]

On Sunday, November 26, 2017 18:58:04 jmh530 via Digitalmars-d wrote:
> On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
>
> wrote:
> > If all of the code is 100% @safe (not system and not trusted)
> > you have a different language where write barriers would be
> > cheaper to implement.
> >
> > Sadly you can’t “skip” write barriers in your @system code
> > because it may run as part of larger @safe. Which is where they
> > are the most costly.
>
> I was thinking you would use a generational or precise GC for
> @safe code and then fall back to the normal GC with
> @system/@trusted code. Not sure if that's possible or not, but in
> my head it would be a separate heap from the @safe code.
> Certainly would be added complexity.

It wouldn't work. @safe code and @system code call each other all the time
(using @trusted where necessary), and they freely exchange stuff that was
allocated on the GC heap. Heck, it's not even possible to have per-thread
heaps (much as that would be desirable), because stuff can be passed between
threads, and you can freely cast between shared and non-shared. You do have
to be careful about it if you don't want to have problems, but just like
@safe code can call @trusted code such that it's possible for @safe code be
calling code that was vetted for memory safety by a programmer rather than
the compiler, you can have code that casts to and from shared and works
perfectly well so long as the programmer vets it properly.

We can't even have different heaps for immutable and mutable stuff, because
it's very common to construct something as mutable and then cast it to
immutable (either explicitly or because it's returned from a pure function
which is able to do the cast implicitly, because it knows that the return
value couldn't possibly have been passed into the function and thus had to
have been allocated inside it).

D's type system protects you from all kinds of dumb mistakes, but it has way
too many backdoors for the kind of stuff that requires that things be locked
down like they would be inside a VM like Java has. Ultimately, if you're
talking about a GC and what it can and can't do, I expect that there's very
little difference between C and D in terms of what you types of GC you can
get away with. D does protect the programmer, but ultimately, it lets you do
just about anything that C lets you do if you really want to, and any GC
that we use has to work with that.

- Jonathan M Davis