Add option GCTrimYoungestKeepPercent to specifies the percent of youngest gen to keep during trimming

[ashaurtaev]

Memory footprint GC latency level allows to reduce memory consumption, but might have effect on application startup time.
This PR adds new config that specifies the percent of youngest gen to keep during trimming, which allows to balance aggressiveness of trimming and effect on startup time.

An example of how this can be used:
DOTNET_GCLatencyLevel=0
DOTNET_GCTrimYoungestKeepPercent=0xF

cc @gbalykov

[dotnet-policy-service]

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

[cshung]

• Do we want to support all formats strtod supports?
• What if the embeddedValue is not a valid floating point number?

[am11]

This will take care of error handling

Suggested change

	*pValue = strtod(embeddedValue, NULL);
	char *endptr;
	double val = strtod(embeddedValue, &endptr);
	if (embeddedValue == endptr) return false; // invalid input; no conversion was performed
	*pValue = val;

[ashaurtaev]

• Do we want to support all formats strtod supports?
• What if the embeddedValue is not a valid floating point number?

Thanks for the review! Do I also need to add error handling for strtoull in ReadConfigValue and ReadKnobUInt64Value?

[ashaurtaev]

This will take care of error handling

Thanks for your advice!

[cshung]

Intentionally reinterpret_cast a 64 bit unsigned integer to a double?

[mangod9]

I am not sure that floating point granularity is required here. Since this increases complexity can you please explain the use case?

[ashaurtaev]

I am not sure that floating point granularity is required here. Since this increases complexity can you please explain the use case?

Thank you for review. We tested various options, for some applications for Tizen there is a difference in results between 2 and 3 and 2.25

[markples]

Thank you for review. We tested various options, for some applications for Tizen there is a difference in results between 2 and 3 and 2.25

Another option would be to scale the initial value up but still divide by an integer. value * 10.0 / divider (or 100)

Beyond the review/maintenance, I think another question would be whether we end up with confusion about whether different variables are ints vs floats. To some extent, my "scale up" comment has a similar problem (i.e., which values are scaled and which aren't?) -- this could be addressed by having the computation be (value / original_divider) * (new_multipler / 100.0) and calling it something like GCTrimYoungestPercentMultiplier. @mangod9?

[Maoni0]

we definitely don't need to add floating point support to our configs just to make this work, you can specify this in percent (or permil even, if you need more precision). so a lot of these changes aren't needed.

but before we consider adding a config, let's step back as @mangod9 said and look at the user case - when you said

We tested various options, for some applications for Tizen there is a difference in results between 2 and 3 and 2.25

what exactly causes the difference? are these your applications or someone else's? are you going to be testing again to see if a slightly different number works better in the future?

[ashaurtaev]

Sorry for the late reply, I was busy with other tasks.

we definitely don't need to add floating point support to our configs just to make this work, you can specify this in percent (or permil even, if you need more precision). so a lot of these changes aren't needed.

Yes, thank you, this solution is also suitable for us.

what exactly causes the difference? are these your applications or someone else's? are you going to be testing again to see if a slightly different number works better in the future?

Difference is related to how the divider value affects the application startup.
Different values of the divider require different amounts of work during GC(trimming GEN 0, etc.) which directly impacts performance.
These are Tizen samples. The impact of the divider appears to be consistent across different types of apps on Tizen.
Yes, we want to be able to tune in the future for other apps. The ability to dynamically adjust this parameter in the future will be especially useful for us to adapt performance to changing conditions.

[ashaurtaev]

A new solution has been added that uses percentages instead of a floating-point configuration.