On Thursday, December 20, 2012 02:37:16 deadalnix wrote:
> D's GC should really be aware of TL and immutability of what it does allocate.

The problem is casting. It's not uncommon to create something as mutable and then cast it to immutable when done. It's stuff like that screws with being able to per-thread GCs. Which thread owns what isn't always clear.

- Jonathan M Davis

On Thursday, 20 December 2012 at 01:54:42 UTC, Jonathan M Davis wrote:
> On Thursday, December 20, 2012 02:37:16 deadalnix wrote:
>> D's GC should really be aware of TL and immutability of what it
>> does allocate.
>
> The problem is casting. It's not uncommon to create something as mutable and
> then cast it to immutable when done. It's stuff like that screws with being
> able to per-thread GCs. Which thread owns what isn't always clear.
>

This is where the concept of island make sense, but this is unreasonable to introduce that in D in any short term.

However, this kind of cast is explicitly specified as unsafe, and can have unexpected consequences, even in today's code. Obviously if the GC start to play with that, consequences will never be the same !!! (and by that I mean the consequences of a misuse can be way more dramatic)

Jonathan M Davis:

> The problem is casting. It's not uncommon to create something as mutable and
> then cast it to immutable when done. It's stuff like that screws with being
> able to per-thread GCs. Which thread owns what isn't always clear.

I nearly never cast mutables to immutable. The purpose of casts is to subvert the type system. If you accept that some type system assumption doesn't hold just because casts exist, then you are doomed to ignore every kind of type system assumption, like immutability, safety, purity, nothrowness, and so on. And this is so wrong. So I can't accept your justification that the existence casts disallow per-thread GCs. Do not use cast that way, and give us a "better" GC.

Bye,
bearophile

On Thursday, December 20, 2012 03:19:17 bearophile wrote:
> Jonathan M Davis:
> > The problem is casting. It's not uncommon to create something
> > as mutable and
> > then cast it to immutable when done. It's stuff like that
> > screws with being
> > able to per-thread GCs. Which thread owns what isn't always
> > clear.
> 
> I nearly never cast mutables to immutable. The purpose of casts is to subvert the type system. If you accept that some type system assumption doesn't hold just because casts exist, then you are doomed to ignore every kind of type system assumption, like immutability, safety, purity, nothrowness, and so on. And this is so wrong. So I can't accept your justification that the existence casts disallow per-thread GCs. Do not use cast that way, and give us a "better" GC.

It's perfectly legal to cast from mutable to immutable. You just have to make sure that you don't have any other references to that data. In many cases, it's the only way to get an immutable version of an object (e.g. if you wanted an immutable AA). There's even a helper function for this in the standard library: std.exception.assumeUnique. There's no way that this is going away, and the GC is going to have to take that into account with however it works. It may still be possible to have a per-thread GC, but it definitely complicates things.

Casting to and from shared has similar issues and happens for similar reasons. And such casts are essentially forced by std.concurrency. So, you're overly optimistic if you think that the GC can ignore such casts. It must take them into account in whatever it does.

- Jonathan M Davis

On Thursday, 20 December 2012 at 02:29:09 UTC, Jonathan M Davis wrote:
> On Thursday, December 20, 2012 03:19:17 bearophile wrote:
>> Jonathan M Davis:
>> > The problem is casting. It's not uncommon to create something
>> > as mutable and
>> > then cast it to immutable when done. It's stuff like that
>> > screws with being
>> > able to per-thread GCs. Which thread owns what isn't always
>> > clear.
>> 
>> I nearly never cast mutables to immutable. The purpose of casts
>> is to subvert the type system. If you accept that some type
>> system assumption doesn't hold just because casts exist, then you
>> are doomed to ignore every kind of type system assumption, like
>> immutability, safety, purity, nothrowness, and so on. And this is
>> so wrong. So I can't accept your justification that the existence
>> casts disallow per-thread GCs. Do not use cast that way, and give
>> us a "better" GC.
>
> It's perfectly legal to cast from mutable to immutable. You just have to make
> sure that you don't have any other references to that data. In many cases,
> it's the only way to get an immutable version of an object (e.g. if you wanted
> an immutable AA). There's even a helper function for this in the standard
> library: std.exception.assumeUnique. There's no way that this is going away,
> and the GC is going to have to take that into account with however it works.
> It may still be possible to have a per-thread GC, but it definitely complicates
> things.
>
> Casting to and from shared has similar issues and happens for similar reasons.
> And such casts are essentially forced by std.concurrency. So, you're overly
> optimistic if you think that the GC can ignore such casts. It must take them
> into account in whatever it does.
>

I think the right way to do that is to actually clone the object. You can argue that is a performance cost, but considering the implication on the GC, I'm pretty sure it is a win.

Another way to do it safely is to use pure function, but it require that notion of isolated island, and as much as I love the idea, I won't be in favor of introducing it right now into D.

On Wednesday, 19 December 2012 at 20:47:39 UTC, Benjamin Thaut wrote:
> An article I just read. It even mentions D:
>
> http://sebastiansylvan.wordpress.com/2012/12/01/garbage-collection-thoughts/
>
> I my opinion he especially has a point with the "each object consists mostly out of pointers" argument.
>
> Kind Regards
> Benjamin Thaut

Another page of interest: http://wiki.luajit.org/New-Garbage-Collector