Allow stack size to be configured for native AOT

[keegan-caruso]

If a native AOT compiled application can lower its allocated memory, more scenarios that are memory sensitive can use it.

The default stack size can be excessive for simple applications and can significantly contribute to the RSS.

For linux, there is the ulimit command, and this is respected, but it can be too broad.

With this trivial code:

int s = 0;

await Task.Run(() => Interlocked.Increment(ref s));

Console.ReadLine();

On linux with the default stack size of 8mb, RSS measured at 5916.

With setting the stack size to 1mb, the RSS measured at 3428.

Roughly a 40% decrease.

[jkotas]

We have (undocumented) IlcDefaultStackSize build property to set the default stack size in Native AOT binaries. Would it be sufficient for what you are trying to do?

[MichalStrehovsky]

This shortcut (making the AppContext switch name same as the environment variable name) makes things inconsistent with how we normally name AppContext switches. See e.g. documented GC switches where DOTNET_gcServer environment variable is a synonym for System.GC.Server host config option (i.e. these are not prefixes and AppContext switches adhere to a naming convention).

It is a bit more work to do this correctly. Sample how it's done on the managed side (also notice the naming convention):

runtime/src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.cs

Lines 66 to 70 in 8fca0a1

	int timeoutMs =
	AppContextConfigHelper.GetInt32Config(
	"System.Threading.ThreadPool.ThreadTimeoutMs",
	"DOTNET_ThreadPool_ThreadTimeoutMs",
	DefaultThreadPoolThreadTimeoutMs);

On the native side we do this (it's what the GC uses to read both env variable settings and host config options):

runtime/src/coreclr/nativeaot/Runtime/gcenv.ee.cpp

Lines 770 to 784 in 8fca0a1

	uint64_t uiValue;
	if (g_pRhConfig->ReadConfigValue(privateKey, &uiValue))
	{
	*value = uiValue;
	return true;
	}
	if (publicKey)
	{
	if (g_pRhConfig->ReadKnobUInt64Value(publicKey, &uiValue))
	{
	*value = uiValue;
	return true;
	}
	}

[jkotas]

Also, it would be nice to keep the configuration capabilities between NAOT and regular CoreCLR the same - make the configuration switch work the same way for both NAOT and CoreCLR.

[keegan-caruso]

@MichalStrehovsky @jkotas

I believe this feedback is addressed. Are there any other changes you would like to see?

This change would help one of the teams that I support.

[MichalStrehovsky]

I believe this feedback is addressed. Are there any other changes you would like to see?

I don't see this comment addressed:

1. The switch name should be something starting with System.Threading.Thread. Maybe System.Threading.Thread.DefaultStackSize? This is a naming convention respected across the entire framework.
2. If I'm reading it right, PalStartBackgroundWork will look at the environment variable, but will not look at RuntimeHostConfigurationOption (the environment variable settings and AppContext/RuntimeHostConfiguration settings are from disjoint namespaces). Is that expected?

[keegan-caruso]

Sorry for the confusion, I pushed 2975db0 awhile ago, but Github wasn't showing the commit in this diff. I followed jkotas's advice, rebasing and force pushed fixed the state.

[keegan-caruso]

We have (undocumented) IlcDefaultStackSize build property to set the default stack size in Native AOT binaries. Would it be sufficient for what you are trying to do?

Thanks. This works on Windows, it is not working for me on Linux.

On windows I checked against kernel32 GetCurrentThreadStackLimits. On linux I checked against strace.

[jkotas]

Thanks. This works on Windows, it is not working for me on Linux.

It works for musl libc (musl libc is used e.g. by Alpine Linux). glibc that is used by the most popular Linux distros like Ubuntu does not respect value set by -z,stack-size linker switch for some reason. That's unfortunate.

[jkotas]

Github status is stuck in "Checking for ability to merge automatically…".

Could you please rebase against main and force push? Hopefully, it is going to reset the status.

[jkotas]

This pattern with Nullable<int> is not thread safe. Nullable is a struct with two fields. This pattern has a race condition caused by tearing.

I do not think you need to cache the value on the managed side. The value is cached on the unmanaged side. You can call every time.

[MichalStrehovsky]

This can use AppContextHelper.GetInt32ComPlusOrDotNetConfig so that we only have one copy of the policy around parsing these.

[jkotas]

Alternatively, this can call into the native runtime to reuse the value parsed there.