Add option GCTrimYoungestDividerValue to tune gen0 trim divider

[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 allows to tune trim divider for gen0, which allows to balance aggressiveness of trimming and effect on startup time. Also, support for floating-point GC configurations is added for better fine-tuning of trim divider.

An example of how this can be used:
DOTNET_GCLatencyLevel=0
DOTNET_GCTrimYoungestDividerValue=2.3

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?