Reduce 99% of allocations when starting processes with derived env vars on Unix

[adamsitnik]

I've noticed that on Unix we allocate way more managed memory than on Windows when starting new Process with default env vars.

On Windows, when the user has not modified the environment variables exposed by ProcessStartInfo, we just don't need to prepare the environment variables block:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs

Lines 482 to 487 in 116bd0d

	string? environmentBlock = null;
	if (startInfo._environmentVariables != null)
	{
	creationFlags |= Interop.Advapi32.StartupInfoOptions.CREATE_UNICODE_ENVIRONMENT;
	environmentBlock = GetEnvironmentVariablesBlock(startInfo._environmentVariables!);
	}

It's derived from the parent process (doc):

A pointer to the environment block for the new process. If this parameter is NULL, the new process uses the environment of the calling process.

According to LLMs, BSD-based Unixes treat NULL passed as envp to execve as "Use the current process environment".
However, I was not able to verify that using existing docs (so even if it's an implementation detail, we should not rely on that).

So let's assume there is documented mechanism to just inherit the env vars from the parent process on Unix.

Both posix_spawn and execve expect char *const envp, which can be obtained just by using environ.

The problem is that environ is global mutable process state (it can be modified using setenv/unsetenv/putenv methods).

But.. fork creates a copy of the parent process and we need to provide the pointer to execve. So my understanding is that it's safe to pass environ obtained after fork to execve.

Which means that if the user has not modified env vars exposed by ProcessStartInfo we can pass null to the native layer (SystemNative_ForkAndExecProcess) and avoid the following:

• creating an array of key=value strings (code)
• allocating an unmanaged memory to hold utf8 representation (code)
• encoding string to utf8 (code)

When I've run such experiment in my proof of concept repo (adamsitnik/ProcessPlayground#43), I got following bechmark results:

156x less memory allocation for synchronous execution (102KB → 0.57KB)
34x less memory allocation for async execution (104KB → 2.6KB)

There are two gotaches:

• BCL itself is not modyfing environ, we would need to make it perform a sys-call after each call to Environment.SetEnvironmentVariable. I believe it's fine as it's rather rare to set your own env vars compared to starting processes.
• If we start using posix_spawn on macOS, we will have to perform such copy or introduce a global shared lock in the native layer.

@tmds @am11 is my thinking process correct? I would like to verify my assumptions before I create a PR.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[tmds]

t can be modified using setenv/unsetenv/putenv methods)

These methods are not thread-safe.

.NET not changing environ means it remains readable for everyone in a thread-safe way and users that want to change it are responsible for the issues that might cause.

I think we want to maintain this behavior.

[jkotas]

These methods are not thread-safe.

We create our own mutable copy of the environment for this reason on non-Windows as you have pointed out in the description.

we would need to make it perform a sys-call after each call to Environment.SetEnvironmentVariable

Nit: I assume you mean setenv/unsetenv/putenv methods. These methods are not syscalls.

[jkotas]

creating an array of key=value strings

This allocation should be avoidable by creating utf8 key=value directly.

To do even better I think we would have to find a way to remember and/or reuse the original strings from envp somehow to avoid allocating the copies.

[am11]

To do even better I think we would have to find a way to remember and/or reuse the original strings from envp somehow to avoid allocating the copies.

Yes, I think the UTF-8 representation of Environment can be saved internally at the expense of excess memory to avoid allocations and conversions at the time of spawning. Otherwise, the alternative approach will at least avoid one intermediary copy with something like:

private unsafe ref struct UnmanagedEnvp
{
    public byte** Ptr;
    public readonly int Count;

    public UnmanagedEnvp(ProcessStartInfo psi)
    {
        int validCount = 0;
        foreach (var (_, v) in psi.Environment) if (v is not null) validCount++;
        
        Count = validCount;
        Ptr = (byte**)NativeMemory.AllocZeroed((nuint)Count + 1, (nuint)sizeof(byte*));

        int i = 0;
        foreach (var (k, v) in psi.Environment)
        {
            if (v is null) continue;

            int byteCount = Encoding.UTF8.GetByteCount(k) + 1 + Encoding.UTF8.GetByteCount(v) + 1;
            Ptr[i] = (byte*)NativeMemory.Alloc((nuint)byteCount);

            var dest = new Span<byte>(Ptr[i++], byteCount);
            Utf8.TryWrite(dest, $"{k}={v}\0", out _);
        }
    }

    public void Free()
    {
        if (Ptr == null) return;

        for (int i = 0; i < Count; i++) 
            NativeMemory.Free(Ptr[i]);

        NativeMemory.Free(Ptr);
        Ptr = null;
    }
}

[adamsitnik]

#126201 was a great improvement, but it reduced "only" 50% of the allocations.

I believe we can still reduce the remaining 50%, either by what I've described here, by caching or by getting a read only snapshot of env vars dictionary.

I am going to reopen the issue and experiment with various approaches and get back with the results. If I can't find a way to get rid of the remaining allocations, I close the issue.