On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
> What language semantics prevent precise & fast GC  implementations?

Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast (generational and/or concurrent) GC. Some more detailed explanations here:
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
> http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

Well, the latest Intel CPUs have a theoretical throughput of 30GB/s... so that makes for up to 30MB/ms.

But language changes are needed, I think.

I also don't quite understand how RC can solve the issue with pointers to internal fields in classes.

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise & fast GC  implementations?
>
> Unions and easy type casting prevent precise GC.
> Lack of write barriers for reference-type fields prevent fast (generational and/or concurrent) GC. Some more detailed explanations here:
> http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

I see... By any chance, can we solve this issue with GC managed pointers? AFAIK, this is what C++/CLR does: There are 2 different pointer types, (*) and (^). (*) is the famous raw pointer, second one is GC managed pointer. A GC pointer has write barrier (unlike raw pointer) so we can have both raw C performance (if we want) and fast generational GC or concurrent GC (which are a magnitude better than a mark and sweep GC).
As you realized, there is a major problem with this: classes. The desicion of making classes reference-type is actually fine (+simplicity), but it doesn't really help with the current situation, I expect D to be pragmatic and let me decide. Maybe in future... Who knows...

On Mon, 08 Feb 2016 11:22:45 +0000, thedeemon wrote:

> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise & fast GC implementations?
> 
> easy type casting prevent precise GC.

To expand on this point:

A GC makes a tradeoff between allocating efficiently and deallocating efficiently. (And a compiler+runtime makes a tradeoff between generating larger binaries that take more time to deal with and being able to produce precise garbage collection.)

You can write a GC that allocates each type in its own region of memory. Every block has a pointer map associated with it. But this means the minimum allocation for each type is one page -- typically 4KB. This is bad for applications that have very few instances of each type and many types of object allocated.

A simpler thing you can do is write a GC that has two regions of memory, one with pointers that might point to GC memory and one without. This gets rid of the overhead problem but doesn't allow precise collection.

Alternatively, a language might prevent all casting, even upcasting, for any type that might contain pointers. Specifically:

class Foo {}
class Bar : Foo {}
Foo foo = new Bar();  // type error!

This means that the GC doesn't ever need to store the type of an allocated object anywhere. It can get the information it needs from a stack map ("pointer to Foo is stored in this stack frame at offset 8") and a similarly formatted map for allocated types.

It would work, but it's sufficiently constraining that I don't think anyone has this in a real programming language.

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
>
> I see... By any chance, can we solve this issue with GC managed pointers?

Maybe we could.  But it's never going to happen.  Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen.

You asked about things that prevent improvement, right?  Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language.  (Never mind that code tends to break anyway.)

-Wyatt

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
> On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
>>
>> I see... By any chance, can we solve this issue with GC managed pointers?
>
> Maybe we could.  But it's never going to happen.  Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen.
>
> You asked about things that prevent improvement, right?  Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language.  (Never mind that code tends to break anyway.)
>
> -Wyatt

Pretty much this.
We can't go a version without code breakage, but also can't introduce features that would drastically help the language because it would introduce breakage.
i.e, all the great ownership/scope/what-have-you proposals and shit like DIP25 gets pushed through instead, then 2 days later it gets proven to be worthless anyways. Woops.

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
> Maybe we could.  But it's never going to happen.  Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen.
>
> You asked about things that prevent improvement, right?  Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language.  (Never mind that code tends to break anyway.)

You are of course right, but it isn't an absolute. Nothing prevents someone to restrict a D compiler in such a way that you can get faster GC.

C++ compilers have lots of optional warnings/errors, so it is quite possible. But I suppose those that want it would rather use Go, C# or some other GC language than can do ahead of time compilation.

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
> On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
>>
>> I see... By any chance, can we solve this issue with GC managed pointers?
>
> Maybe we could.  But it's never going to happen.  Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen.
>
> You asked about things that prevent improvement, right?  Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language.  (Never mind that code tends to break anyway.)
>
> -Wyatt

I have no special knowledge but strikes this observer that they are serious about working on solutions (whether that's a better GC or alternatives or both).  But some patience required as its not such a straightforward problem and its better to take time than rush and make a mistake.  It wasn't all that long ago that Andrei quit and I guess he moved across country and it certainly takes time to sort out one's home office and find a new working pattern.

The discussions in the mailing list are quite interesting although beyond my technical knowledge for now.

The GC itself may still be far from perfect but its much better than it was, and there are more options now.  I have found emsi containers (built on top of Andrei's allocator) pretty nice myself for my own use.

On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
> The GC itself may still be far from perfect but its much better than it was, and there are more options now.  I have found emsi containers (built on top of Andrei's allocator) pretty nice myself for my own use.

Well, GC being better than it used to be doesn't change the fact it's still the worst of it's kind. I don't know if this[1] work actually got released or merged but looks like it's abandoned. Pretty sad as it seemed very promising.

Anyway, I was expecting a lot more people to tell their specific problems, like "bla bla design desicion makes ARC incredibly dangerous and we can't properly interface with Objective-C without that" or like "bla bla D feature overlaps with some other stuff and requires redesign to be solved" or maybe "being unsafe (@system) by default breaks the deal"...
GC is just one of the hundreds of problems with D and it was an example rather than the main point in this thread but thanks for anyone who replied.


[1] http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmars-d@puremagic.com

On Monday, 8 February 2016 at 17:51:02 UTC, Ola Fosheim Grøstad wrote:
> C++ compilers have lots of optional warnings/errors, so it is quite possible. But I suppose those that want it would rather use Go, C# or some other GC language than can do ahead of time compilation.

There are several reasons I want to use D rather than C# / Go / something else:
- Interfacing with native API without jumping through hoops
- Incredibly high abstraction and meta-programming possibilities with relatively easier syntax + semantics.
- It's harder to reverse engineer native code than byte code equivalent.
- Trading off anything according to your needs.
- Expressiveness and purity, immutablity concepts.
- Having GC (but not a horribly slow one)
- Syntactic sugars (associtive arrays, powerful foreach, slices...)
- Compile times
- Not bound to a specific platform (unlike C#, easier to do cross-platform work in many cases)


I wish D could be better. I really want it with all of my heart...