Migrating an existing more modern GC to D's gc.d

[Jonathan M Davis]

On Tuesday, April 10, 2018 07:55:00 David Bennett via Digitalmars-d wrote:
> On Tuesday, 10 April 2018 at 06:47:53 UTC, Jonathan M Davis wrote:
> > As it stands, it's impossible to have thread-local memory
> > pools. It's quite legal to construct an object as shared or
> > thread-local and cast it to the other. In fact, it's _highly_
> > likely that that's how any shared object of any complexity is
> > going to be constructed. Similarly, it's extremely common to
> > allocate an object as mutable and then cast it to immutable
> > (either using assumeUnique or by using a pure function where
> > the compiler does the cast implicitly for you if it can
> > guarantee that the return value is unique), and immutable
> > objects are implicitly shared.
>
> (Honest question:) Do people really cast from local to
> shared/immutable and expect it to work?
> (when ever I cast something more complex then a size_t I almost
> expect it to blow up... or break sometime in the future)

Yes. They expect it to work, and as the language is currently designed, it
works perfectly well. In fact, it's even built into the language. e.g.

    int[] foo() pure
    {
        return [1, 2, 3, 4];
    }

    void main()
    {
        immutable arr = foo();
    }

compiles thanks to the fact that the compiler can guarantee from the
signature of foo that its return value is unique. We also have
std.exception.assumeUnique (which is just a cast to immutable) as a way to
document that you're guaranteeing that a reference to an object is unique
and therefore can be safely cast to immutable.

> That said, I can understanding building a shared object from
> parts of local data... though I try to keep my thread barriers as
> thin as possible myself. (meaning I tend to copy stuff to the
> shared and have as few shared's as possible)

Because of how restrictive shared and immutable are, you frequently have to
build them from thread-local, mutable data. And while it's preferable to
have as little in your program be shared as possible and to favor solutions
such as doing message passing with std.concurrency, there are situations
where you pretty much need to have complex shared objects. And since D is a
systems language, we're a lot more restricted in the assumptions that we can
make in comparison to a language such as Java or C#.

- Jonathan M Davis