Future of memory management in D

[tchaloupka]

On Wednesday, 17 November 2021 at 13:44:39 UTC, Adam D Ruppe 
wrote:
> On Wednesday, 17 November 2021 at 12:14:46 UTC, tchaloupka 
> wrote:
>> * it's hard to tell anyone that GC in D is fine when you look 
>> at techempower benchmark and searching the vibe-d (or anything 
>> in D) somewhere up where it should be and isn't (event other 
>> GC languages are much higher there)
>
> I'm pretty sure you're the one who benchmarked my cgi.d and it 
> annihilated vibe.d in that test.
>
> Maybe it isn't the GC and vibe is just poorly written?

Yeah, that was me ;-)

In case of the techempower one problem with GC is, that it is 
tested on a CPU with many cores. For each of them there is one 
thread to manage clients (using `SO_REUSEADDR`/`SO_REUSEPORT`). 
There would be a problem with a `stop the world` GC as it would 
stop all of them. In case of the web server there would be better 
to use some allocator that just allocates as needed in a scope of 
currently handled request and discards all of it back on request 
completion. Something like this is used in nginx module 
implementation for example.
Or one would need to manage a set of subprocesses to avoid others 
to be stopped on GC collection.

But then you'll start making workarounds for the GC, start to 
manage memory manually here and there and then you realize that 
you would probably be better without the GC in the first place. 
Sometimes it just won't scale.

GC would also add some syscalls overhead as it uses signals, 
eventfd, etc.

Of course there would also be places in vibe that are suboptimal, 
it's not only about the GC. Maybe even fibers alone won't be as 
lightweight compared to rust/c++. Rust has also a  stealing 
scheduler with waitfree/lockfree queues.