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

[Manu via Digitalmars-d]

On 13 May 2014 14:39, Kagamin via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Saturday, 10 May 2014 at 19:17:02 UTC, Xavier Bigand wrote:
>>
>> My concerns as Dlang user are :
>>  - Even if GC is the solution, how long I need suffer with destructor's
>> issues (calls order)?
>
>
> What issues do you have with destructors and how they affect you?
>
>
>>  - When we will able to see a performant GC implementation can satisfy
>> someone like Manu :) ? Months, years, a decade?
>
>
> Neither GC nor C heap will satisfy Manu's requirements. When it comes to
> shooters, the only way is to not allocate and write accurate code, even in
> C++. Even substitution of allocator won't help him, if the code relies on GC
> in a non-trivial way.

I'm not quite sure what you're saying, but I don't think it's quite as
stringent as you suggest, at least, not anymore. We so try to minimise
allocations, but some dynamic memory usage is just a modern reality.
There is only a single requirement I see for automatic memory
management to be practical, and it is very simple; time associated
with whatever memory management needs to be fine-grained and evenly
distributed. It needs to be amortised in some way.

This obviously lends itself to eager-freeing systems like ARC. If a GC
can be made that is reasonably nonintrusive; like one that is decently
concurrent, ideally incremental in some way, maybe has split pools,
where a high-frequency/small-allocation/temporary pool (ie, runtime
temp data, closures, strings) may clean up very quickly without
resulting in full memory scans... maybe it's possible. I don't know.
The problem is, it's been years, nobody seems to know how to do it.
It's still not clear that would be acceptable, and I have no reason to
believe such a GC would be higher performance than ARC anyway... but
I'm more than happy to be surprised, if someone really thinks it can
be done.

The other topic is still relevant to me too however (and many others).
We still need to solve the problem with destructors.
I agree with Andrei, they should be removed from the language as they
are. You can't offer destructors if they don't get called. And the
usefulness of destructors is seriously compromised if you can't rely
on them being executed eagerly. Without eager executed destructors, in
many situations, you end up with effective manual releasing the object
anyway (*cough* C#), and that implies manually maintaining knowledge
of lifetime/end of life and calling some release. I see memory
management as a moot offering as soon as that reality exists.
If we do end out with a GC that is somehow acceptable (I'm still
skeptical), then this discussion about what to do with destructors is
still ongoing.

Do we ARC just those objects that have destructors like Andrei
suggested? It's a possibility, I can't think of any other solution. In
lieu of any other solution, it sounds like we could very well end up
with ARC tech available one way or another, even if it's not
pervasive, just applied implicitly to things with destructors.