Classes on stack

[Steven Schveighoffer]

On 9/1/22 4:11 PM, Johan wrote:
> On Thursday, 1 September 2022 at 13:23:42 UTC, Steven Schveighoffer wrote:
>> On 9/1/22 6:13 AM, Redwan wrote:
>>>
>>> OK tnx. another problem that probably is related to this issue.
>>> I compiled this worthless code:
>>> ```
>>> void main() {}
>>> ```
>>>
>>> also this one:
>>> ```
>>> @nogc void main() {}
>>> ```
>>>
>>>
>>> the valgrind result:
>>> ```
>>> ...
>>> total heap usage: 143 alloc, 141 frees, 13,236 bytes allocated
>>> ...
>>> ```
>>>
>>> !!!
>>> what's this means??
>>> from where comes this allocations and also leaks???
>>
>> The runtime does some allocations before running main. But these are 
>> all C malloc allocations and not GC allocations. There should be zero 
>> GC usage in these programs.
> 
> Hi Steven,
>    I think you would agree that one hundred and forty three allocations 
> (=malloc calls?) is a very large (unacceptable) amount for just starting 
> and shutting down the runtime of D.

I think it's malloc and realloc. No I don't think that is too much. How 
much would be acceptable for you?

One thing I can think of that I was personally involved with that does 
allocations is the module sorting algorithm (used for detecting cycles 
and proper ordering of module ctor/dtor). This allocates and deallocate 
temporary structures to do the directed graph sorting. 143 seems like 
quite a lot for that, I would still be interested to see what all the 
*exact* allocations are.

It also probably allocates the string array for the main args.

> 
>> As for "leaks", I think it would tell you that. Looking on the 
>> internet, this may count for "reachable" data, that is, data that is 
>> allocated, and still referenced at program exit. Such memory is not a 
>> "leak" in the sense that you just stopped pointing at it and never 
>> freed it.
> 
> Matching deallocations should also be required of a language runtime. 
> Every user is forced to use the druntime, it is not an optional 
> component (yes -betterC, come on). One example mentioned on 
> StackOverflow is the case of a DLL [1].

The allocation done by rt_init should be deallocated by rt_term, and 
clearly it's not. If there is not a bug report on that, there should be.

The ones done by pragma(crt_constructor) I don't know how that works in 
terms of having dlls. So maybe that one is OK.

On a somewhat related note, I wish that there would be a way to avoid 
the module constructor sorting at runtime, because it is the same every 
time, and a waste of CPU cycles to do it. But this can only be done 
*after* linking. If there were some way to preallocate space for the 
module ctor cycle order, and then run a post-build step to edit that 
graph, it would be a great improvement to have.

-Steve