radical ideas about GC and ARC : need to be time driven?

[via Digitalmars-d]

On Saturday, 10 May 2014 at 19:17:02 UTC, Xavier Bigand wrote:
>  - When we will able to see a performant GC implementation can 
> satisfy someone like Manu :) ? Months, years, a decade?

Never, Manu wants to do fine granularity allocations.

>  - Same question if D migrate to ARC?

You probably also need to use an autorelease pool for realtime 
callbacks and add whole program analysis to avoid exessive ref 
counting.

> For DQuick we completely loose our motivation cause of the lack 
> of clear plans on decisions in the language having a deep 
> impact on this project.

Yes, evolutionary drift is a key problem. Not having worked out 
the core memory model before adding language features is also a 
problem

> Don't forget the ecosystem around the language will also take 
> years to grow before coming really interesting.

For applications, yes.

But I don't think that is true for a system level language...  A 
solid language and compiler with minimal runtime requirements 
would cut it.

> In my sens C++ fails to evolve cause of conservative decisions, 
> Apple with Clang work on include removal. I'd prefer to see the 
> C++ community took this decision to make it standard even if it 
> break the language.
> I would be sad to see D, making the same.

D is limiting itself by:

1. Requiring C/C++ compatible runtime for all threads. You could 
do better by having some threads with no FFI.

2. Limiting breaking changes for a development branch...

3. Having 3 different backends. Language design does affect 
IR/backend if you eant performance. Rewriting 3 backends is... 
Not realistic,

> If phobos comes allocation free or use allocators, then it will 
> be easier to migrate from one memory management to an other one.

Phobos is a non-issue, language constructs and runtime is the 
primary issue. (you can have a real time library)

> In conclusion would be possible to migrate to ARC if the time 
> gap in comparison of an ideal implementation of GC is of the 
> order of many years or a decade?

No, because it still won't perform well with multi threading and 
by that time CPUs will support transactional memory. RC kills 
transactions by doing writes.

Isolates are easy to do, but they are not performant.