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