On Sunday, 4 October 2015 at 17:30:39 UTC, rsw0x wrote:
I still say it's worth investigating a thread-local GC by taking advantage of the fact that shared has never really been properly fleshed out. This would heavily play to D's TLS by default, and preferring message passing over shared data.
That would be ideal but gets really nasty for a number of reasons - primarily having to do with casting. It's perfectly possible to cast to and from shared and much easier to create something as thread-local and then cast it to shared than to create it as shared, so you very quickly run into problems with objects being created on heap but really needing to be used on another. Another major issue is message passing, because in order to avoid copying, you basically need a way to move an object from one thread-local heap to another. Right now the way you'd do it is to cast to immutable to pass the object and cast it back to mutable on the other side (which is _far_ from ideal). Using shared would be better, but the last time I checked, Variant has issues with it so that that didn't work with std.concurrency. Regardless, the fact that you're casting to pass across threads again runs into issues with objects being created on a particular heap but then needing to be moved to another. _Maybe_ that could be resolved by making casting to and from shared do a lot more work underneath the hood, but that get's _really_ complicated when you start having objects that refer to other objects and the like.
So, having a thread-local GC _sounds_ like a great idea, but it's not at all clear that we can actually pull it off given how much you're allowed to do in D. There can be some serious downsides to not placing major restrictions on the user like languages like Java or Go tend to do.
- Jonathan M Davis
