On Sunday, 4 October 2015 at 21:01:45 UTC, Jonathan M Davis wrote:
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
Most of these issues are addressed by fleshing out shared, it was
already put as a 'priority' last year by Andrei but nothing was
ever done.
If you design a language around having a GC, but do not provide
GC friendly mechanisms, the GC will never be good for the
language. Java would never have a GC better than a simple mark
and sweep GC if it didn't provide help to the GC.
Designing shared around the GC just happens to be a way to do it
without affecting the runtime performance of D at all unlike e.g,
pointer barriers. If D has no intentions of aiding the GC, then
the GC should just be dropped because it's basically just
slapping Boehm on C++ right now.
bye.
