std.process: memory allocation with malloc in execv_

[Steven Schveighoffer]

On 1/31/23 1:45 PM, kdevel wrote:
> On Tuesday, 31 January 2023 at 15:29:35 UTC, Steven Schveighoffer wrote:

>> Using `GC.disable` ensures the GC will not run when you allocate memory.
> 
> That leads directly to an avoidable allocation failure if there is no 
> free memory but enough memory which could be reclaimed in order to 
> allocate `argv_` (the array of pointers to C strings).

The GC will still run if it runs out of memory as a last-ditch effort to 
reclaim some memory.

https://github.com/dlang/dmd/blob/b3129254c8e4c25043bc11f820e5d8ea323ac603/druntime/src/core/internal/gc/impl/conservative/gc.d#L1947

But even if this wasn't the case, this is such a rare occurrence to try 
to avoid that I think the pros of not running a collection in every 
other case is worth this drawback.

> 
>> Whether it runs or not is up to the memory allocator.
> 
> That is the way how systems with GC appear to work since the sixties? Is 
> there a "guideline" that Phobos functions shall **not** be implemented 
> in plain vanilla D? I mean: There is little point in using a GC managed 
> allocation when you have to switch the GC off every now and then.

This isn't every now and then, this is literally right before the 
process is about to be obliterated, and all the memory the GC just 
reclaimed for us will immediately be reclaimed by the OS. It's the 
embodiment of wasting cycles. If we can help it, we should avoid it.

>> Running a collection just before replacing the entire image with 
>> another program isn't productive work.
> 
> Can you quantify the likelihood of such incidents and the impact 
> (performance, electrical power, money loss) of a GC not switched off 
> before `execv*`?

What are you talking about?

> 
>> Just add:
>>
>> ```d
>> GC.disable;
>> scope(exit) GC.enable;
>> ```
>>
>> to the part where you are about to set up the call to `exec`
> 
> To me there is no benefit of doing so. However, it makes the code more 
> complicated and hence less readable.

If you like wasting CPU cycles for no gain, go ahead and see if it works 
for you. This isn't going to change anything incredibly significant. The 
memory corruption definitely should be fixed either way.

I'm done with this thread, you don't seem interested in fruitful 
discussion. Do what you will.

-Steve