Future of memory management in D

[Ola Fosheim Grøstad]

On Wednesday, 17 November 2021 at 14:01:31 UTC, Adam D Ruppe 
wrote:
> On Wednesday, 17 November 2021 at 13:50:59 UTC, Ola Fosheim 
> Grøstad wrote:
>> Your whole instance might boot on 256-512MiB.
>
> I've had no trouble running normal D on that right now.

Ok, but it depends on how much garbage you create. For instance 
if you want to process very large images on the same instance you 
might run into trouble. Although I guess you could preallocate a 
large buffer at boot and only do one image at the same time. But 
if you need to buffer many large data items at the same time you 
can run into fragmentation issues. This is not so uncommon as you 
often might want to cache files in memory. I guess one option 
here is to use weak pointers and let the GC evict items from the 
cache, but then we need weak pointers… Ok, can be a library type 
maybe, but then we are back to ownership and borrowing.

With precise collection you have some chance to reduce 
fragmentation. For instance if you collect when no requests are 
pending then you should ideally have no fragmentation. But a 
proper GC language can do compaction… so that is a GC advantage. 
D cannot really offer compaction even in theory?

I think cloud services should have a dedicated runtime.

In short: It is not so trivial if you want to offer advantages 
over other languages. A primitive GC, is just that, primitive.

> https://github.com/dlang/druntime/blob/master/src/core/internal/gc/os.d#L218
>
> Notice the Linux implementation....... lol.

Ouch. If you know the instance size I guess you also could 
hardcode the limit and just claim all the memory you ever want at 
startup.

But, I don't think web-services really is an area where D should 
try to be highly competitive, that is much more of a high level 
programming arena.

I guess some services can benefit from system level programming 
in 2021, but in the long run, no.