Future of memory management in D

[tchaloupka]

Thanks Steve.

On Wednesday, 17 November 2021 at 17:19:31 UTC, Steven 
Schveighoffer wrote:
> I have to say, the second I see "How to X with DLL" in this 
> forum, I mark as read and continue. D has a horrible story on 
> DLLs, and it's been like that for as long as I can remember. If 
> there is some infrastructure project that needs attention, it's 
> DLLs. You are right that `betterC` and `importC` are useless if 
> using D from C is nigh impossible or so difficult even the 
> experts can't tell you the answer.
>
> HOWEVER -- there is no excuse for the runtime hanging when a 
> possible error is detected from a system call. Your linked 
> discussion was not resolved how it should have been. Either the 
> runtime should deal with that result properly, or it should 
> crash the application completely. Not properly handling system 
> call errors deep in the runtime is not acceptable.
>
> If no bug has been filed on this, please do.

After the experience we've ended up with a workaround that passes 
requests from C# threads to single thread managed by D's runtime. 
It works kind off. It's not pretty or most effective, but at 
least it doesn't crash. Only on DLL unload it has problems 
sometimes but that is only on program exit anyway so not a big 
deal for us.

But if I'd do something differently now, I'd end up using betterC 
only library for this case and avoided runtime completely.

>
> I believe the GC can be tuned to reduce this, as long as you 
> haven't at one point needed that much memory at once.

Yes, we have found some settings that makes it better (highest 
impact has progressive growing of the allocated pages set to 1).

>
> However, it is worth noting that GC (in any language) generally 
> does require more memory than manual allocation or reference 
> counting. D does not have the ability to use a moving GC, 
> because of the type system, which makes compacting GC 
> impossible unfortunately.

Yes it's expected but when I've seen the reported numbers of what 
is allocated and how much of that is actually free I had my 
doubts that it is caused only by fragemtation.
But there are no official tools, nor druntime facility to make 
some GC memory map of what is actually there and where so it's 
pretty hard to tell and diagnose this.
I've ended up using linux debuging tools to at least see when it 
allocates next page from what stack, but too many allocations 
rendered it impossible to process (but at least lead us to the 
dpq2 allocation problem). After that it became much better so 
we've decided to move it back to backlog as it would require much 
more time to move further).

>
> Oof, the `dpq2` library should fix that (probably malloc/free 
> the temporary C string). Have you filed a bug on that?

Nope, just internal patch, but I've fixed that: 
https://github.com/denizzzka/dpq2/issues/161

>
> If I can separate the use cases here, using D as a main 
> application, on a normal modern server/desktop, I have found 
> using the GC to be a non-issue.
>
> There are problems clearly with:
>
>  * using D with GC as a plugin
>  * using GC in a memory/resource constrained environment
>
> Does that sound fair?

Yes, there are uses where GC is not much of a problem and when 
is, it can be worked around where it makes sense.

>
> This doesn't make sense, as I believe async/await in languages 
> enables the compiler to rewrite your functions into a state 
> machine. How it stores the state might not need GC usage, 
> because the compiler is in control of the state creation and 
> the state usage.
>
> I wouldn't expect it to need more GC abilities than 
> `scope(exit)` does.

I might be wrong, but I guess there would be more to it as a 
scheduler that would control where the work is actually done 
controlling some `Future`/`Promise` facilities. And when it comes 
to Thread/Fiber synchronization, then..

But I'm not an expert in this field and as you, I'm more used to 
seemingly blocking API that is possible in vibe-d/mecca.

>
> If you refer to UFCS and/or templates, I'm not sure how 
> solvable a problem this is.

No this is more about that it just stops working completely and 
needs the restart. I can understand that not all code completion 
is possible, but in this case what has worked just stops working. 
Not sure why or where (might be a project organization with many 
subprojects in a relative paths, etc.). But as I said, I'm used 
to it. This is more about newcomers that might be scared away ;-) 
For debugging I use printf/gdb and I can live with that.

> Having the other options is a nice possibility, but I would be 
> very much against removing the GC, or refactoring everything so 
> I have to think about non-GC options.

We're on the same page here. I'd also like the best of both 
worlds ;-)
Removing `betterC` or forcing GC on user would be a show stopper 
for me too.

>
> Such is life. If you want an ecosystem built around a certain 
> paradigm or low level design choice, you have to either create 
> it or get others to join you in that paradigm.
>
> D does give you the opportunity to do that, it certainly does 
> take a lot of critical mass to do that.
>

Yes, unfortunately I haven't found any other language that I 
would like more. So even with its quirks, D is great but 
definitely deserves to be better.