[Question] CoreCLR low memory footprint configuration

[alpencolt]

We are applying CoreCLR for devices with low RAM and interesting to reduce application's memory consumption. But as you understand such kind of optimizations decrease overall performance usually.

So there is idea to make CoreCLR configuration which enable some JIT optimization (like JIT pitching) or disable (like inlining), which also enable some runtime optimizations which decrease memory consumption.
Is it possible to merge such configuration to upstream? May be do you have already some ideas or proposal for it?

@jkotas @janvorli @BruceForstall
cc @Dmitri-Botcharnikov @gbalykov @kvochko @sergign60 @mlabiuk

[ViktorHofer]

That might also affect the shared ArrayPool as it caches various types up to a limit of X

[jkotas]

We do have various build config switches that lets you configure this. Are you asking whether we can have one build switch that sets multiple of other build switches?

That might also affect the shared ArrayPool as it caches various types up to a limit of X

The ArrayPool needs to be integrated with the GC so that it does not leak memory: https://github.com/dotnet/corefx/issues/25841 or https://github.com/dotnet/coreclr/issues/7747. The GC has configurable policies on what to optimize for (#15469). Once the ArrayPool is integrated with the GC, this should naturally fall out.

[alpencolt]

@jkotas I'm asking about possibility to add more optimization which decrease memory consumption to upstream. It's not interesting for server applications (as I guess main target for Microsoft) but fit well for smartphones.
And because it's "target specific" optimizations I propose to add one build switch for this configuration.

[jkotas]

Majority of these can be just configurable policies. They do not need to be runtime build-time switches. For example, you can choose between server GC and workstation GC for netcoreapp today. Different templates have different defaults for these switches. Console apps default to workstation GC and ASP.NET default to server GC. Similarly, the template for Tizen apps can have different defaults.

The code-pitching is outlier because of it is not implemented pay-for-play and does not work well with debuggers/profilers, so that one is a build switch.

[alpencolt]

Right, build-time switches aren't needed for things like GC. But what if want to remove relocation of *.ni.dll files on loading. It will decrease launching time and allows to share libraries between processes on Linux, but it decrease overall performance since all code will be PIC. Or for example we can change structure of some tables with meta-data.
Will be it build time time or runtime options is the second question. First of all I'm interesting about possibility to merge such optimization with "penalty" to upstream. Of course will be better to have some knob which enable low memory configuration, but we can do it in our configuration files.

P.S.
I'm not ready to share list of optimizations we need to make more estimations.
If you know some points to look I will be very grateful.

[jkotas]

what if want to remove relocation of *.ni.dll
Or for example we can change structure of some tables with meta-data.

These can be command line option for crossgen. Also, for PIC code - I think we would likely want to make it the default.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.