Enable overriding default stack size on Windows

[pakrym]

When hosting CoreCLR inside IIS using AspNetCoreModule it inherits stack sizes from w3wp.exe that are smaller then default (512K in 64 bit version and 256K in 32bit one.).

Customers started hitting stack overflow exceptions in apps that used to work because of that: https://github.com/aspnet/AspNetCore/issues/4531 dotnet/efcore#14116

Would be nice if we can give them a way to increase managed stack size similar to dotnet/coreclr#13517

@janvorli @jkotas

[pakrym]

This is made worse by having tiered JIT enabled by default. The first pass generates methods that use stack space pretty generously resulting in even reasonable scenarios failing with SO.

@davidfowl @shirhatti

[GSPP]

It also would be good to be able to lower stack size. In high thread count scenarios this can be beneficial.

In my experience the default size is very big and very unlikely to be exceeded. I wonder why the EF scenario is hitting that limit. That looks like either an EF or a JIT problem.

[jeffschwMSFT]

@sdmaclea can you take a look at this issue. This is having an impact on our web scenarios.

[sdmaclea]

@janvorli's solution in dotnet/coreclr#13517 was based on an environment variable.
@pakrym Is that really sufficient solution? Seems clumsy for customers

[pakrym]

It was based on runtime settings as far as I understand and they could be set from .csproj via runtimesettings.json same way we do for tiered JIT (https://blogs.msdn.microsoft.com/dotnet/2018/08/02/tiered-compilation-preview-in-net-core-2-1/ see Trying It Out section)

[jkotas]

It was based on runtime settings as far as I understand

That's not correct. It was a environment variable read very early in the process as @sdmaclea said.

[pakrym]

My bad. Was there a reason not to use a runtime setting?

[janvorli]

@pakrym On Linux distros based on MUSL, we need to use that value early during PAL initialization to set the size of the primary thread stack. That happens before anything from the runtime is initialized. However, we could change PAL_InitializeCoreCLR to take the stack size as a parameter and create a new version of the coreclr_initialize hosting API that would take the stack size as a parameter too. Then the host can get it even from runtimesettings.json (I think the host processes it, but I am not sure) and pass it to the new version of coreclr_initialize.
Finally, we would probably need to create a new version of ICLRRuntimeHost interface that would allow us to pass in the default stack size so that the runtime can keep it.

[jkotas]

create a new version of the coreclr_initialize

You do not need to. It can just be a new key/value pair.

[martincostello]

Is this likely to be addressed as part of the 3.0 release? It's currently a blocker to use of in-process hosting for a number of applications I help maintain.

[sdmaclea]

@vitek-karas @elinor-fung Can we add this to the new native hosting API proposal? See https://github.com/dotnet/coreclr/issues/21450#issuecomment-455114478 & https://github.com/dotnet/coreclr/issues/21450#issuecomment-455145007

[vitek-karas]

The native hosting proposed in dotnet/core-setup#5336 will make it possible for the ASP.NET host to set a runtime property.
It is absolutely possible to consume runtime properties during PAL intialization. coreclr_initialize currently takes a parameter with the path to the exe which is used during PAL initialization. We can relatively easily query the properties collection passed to coreclr_initialize as well and take the stack size from there before calling PAL initialization.

I think this can be resolved on its own without the native hosting API changes, those will just make it easier in the ASP.NET scenario to use the feature added by this.

[sdmaclea]

@martincostello This should make 3.0

[analogrelay]

Is there an eta on making it possible to override the default stack size? We have reactionary work we want to do in our IIS hosting model to use it.

[sdmaclea]

I started looking at this last week. I expect to get back to it this week (but it is my 5th priority). I suspect it won't be to bad. It may miss coreclr preview5, but should be in preview6.

[analogrelay]

Cool, that's fine, I just wanted to get an idea of the timeline :).