Read public GC options if available

[kant2002]

Also pass RuntimeHostConfigurationOption into --runtimeopt ILC parameter Fixes : #85961

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Also pass RuntimeHostConfigurationOption into --runtimeopt ILC parameter Fixes : #85961

Author:	kant2002
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[MichalStrehovsky]

These configuration names come from different "namespaces". Like I wrote in #85961 (comment) "We need to either add another blob with the new values, or come up with some sort of mangling so that we can store both key/value pairs in the same blob. I don't have an opinion. Whichever looks better."

The approach in this PR will run into issues as soon as there's a conflict between a "Config" name and "Knob" name. Here's how CoreCLR implements this:

runtime/src/coreclr/vm/gcenv.ee.cpp

Lines 1158 to 1176 in 0b5f137

	if (CLRConfig::IsConfigOptionSpecified(configKey))
	{
	CLRConfig::ConfigDWORDInfo info { configKey , 0, CLRConfig::LookupOptions::Default };
	*value = CLRConfig::GetConfigValue(info) != 0;
	returntrue;
	}
	elseif (publicKey != NULL)
	{
	if (MultiByteToWideChar(CP_ACP, 0, publicKey, -1/* key is null-terminated */, configKey, MaxConfigKeyLength) == 0)
	{
	// whatever this is... it's not something we care about. (It was too long, wasn't unicode, etc.)
	returnfalse;
	}
	if (Configuration::GetKnobStringValue(configKey) != NULL)
	{
	*value = Configuration::GetKnobBooleanValue(configKey, false);
	returntrue;
	}
	}

CLRConfig::GetConfigValue is the moral equivalent of RhConfig. It will try reading the value from embedded config or from a DOTNET_ prefixed environment variable with that name. Configuration::GetKnobStringValue reads the value from the JSON on the other hand. We miss the other thing. I don't think making CLRConfig::GetConfigValue do the other thing is the right approach.

[MichalStrehovsky]

Thanks for taking up the challenge!

[MichalStrehovsky]

We just switched ReadConfigValue from TCHAR to char*. Could you rebase against latest main and apply similar changes as in #86393? Cc @elinor-fung

[MichalStrehovsky]

decimal = false doesn't look right - we don't pass this as true for GC settings but the GC settings in runtimeconfig.json are documented to be decimal (as opposed to the GC settings set through environment variables that are hex).

In fact, do we need the hex support in knobs?

[MichalStrehovsky]

We should use UTF-8 - users can dump anything they want into RuntimeHostConfigurationOption ItemGroup.

Suggested change

	byte[]optionBytes=System.Text.Encoding.ASCII.GetBytes(option);
	byte[]optionBytes=System.Text.Encoding.UTF8.GetBytes(option);

[kant2002]

What about honoring COMPlus_XXX environment variables while I'm in this location?

[MichalStrehovsky]

We should be already honoring the DOTNET_ prefixed ones. Reading from environment variables is the major difference between "knobs" and "switches".

[kant2002]

Yes DOTNET_ is honored, but in the docs still exists old one COMPLUS_, and I thinking about adding that support for switches and not knobs. Just I see it is as supported (not sure for how long) and I suspect that after some time would be customer request for that.

[jkotas]

COMPlus_ prefix for env settings is deprecated. We do not need to give it a new life in native AOT. We can add stronger wording in the docs to use DOTNET_.

[MichalStrehovsky]

TODO: compare with coreclr - is this case insensitive?

[MichalStrehovsky]

Whoops, that TODO was for me, but might as well dump it on you :). Can you compare how this is done in CoreCLR?

[kant2002]

casesensetive comparison always. for knobs and configs.

[MichalStrehovsky]

RCV_Count only make sense if we know the upper bound because this is not something that is user-configurable. RuntimeHostConfigurationOption is unbounded. We need to keep track of the real count. (Same comment applies to other uses of RCV_Count in this file)

[MichalStrehovsky]

The new methods look very similar to the existing ones. Can we share them?

[MichalStrehovsky]

If we share, we'd delete the concept of RCV_Count.

[MichalStrehovsky]

Note that there's another PR in flight making changes here so we might want to pause for a moment to avoid conflicts. #86656 cc @elinor-fung

[kant2002]

I do not sure if sharing make things better, but please take a look.

[MichalStrehovsky]

This won't work for settings that specify true/false. Could you mirror how this is handled in CoreCLR?

[MichalStrehovsky]

Thank you!

[kant2002]

Looks like you are tired to babysit me 😄 thank you!

[MichalStrehovsky]

Looks like you are tired to babysit me 😄 thank you!

It was already close enough that we could avoid another round :). Thanks!