Temporally safe by default

[Dukc]

On Wednesday, 10 April 2024 at 19:59:46 UTC, Sebastiaan Koppe 
wrote:
> On Wednesday, 10 April 2024 at 12:31:03 UTC, Dukc wrote:
>> [...] since deteministic memory management is so rarely needed
>
> By whose count? I've found there are plenty of places where 
> they make a difference.

One clarification: I meant heap memory management. Stack memory 
objects obviously get freed deterministically but I didn't mean 
those.

Another clarification: I meant rarely needed compared to the GC. 
Not rarely as in "unlikely that you personally should ever do it".

Both my own count and of what others have written in this forum. 
On my own code, I almost always use the GC. While I can imagine 
doing manual freeing on a few critical places if I want to 
optimise, it's far far less often needed than the GC (and would 
be even less needed if we had a generational GC that performs 
better).

Well, on my old Spasm code where I don't have the GC, I do resort 
to deterministic heap management fairly much, but a better answer 
in the long run would be having some sort of portable GC instead 
of managing the heap with other means. Even if ref counted memory 
was as simple to use as the GC (which it cannot be), you'd want 
the GC just to be able to use existing D code out of the box. 
This also applies to a bare-metal project: a scheduler or low 
level device driver code might need or want to use other means of 
memory management for latency or performance reasons, but in all 
likelihood it's going to be only a minority of the code. Someone 
just recently linked a blog post demonstrating how a GC is 
extremely relevant even in systems programming.

Even if it's a hard real-time system, it can be done by keeping 
the critical real-time thread outside the world the GC stops, but 
delegate everything possible to normal GC-controlled threads.