Skip to content

Conversation

@am11
Copy link
Member

@am11 am11 commented Sep 30, 2022

Also delete the (now-unused) internal CommandLine implementation.

@ghost ghost added area-crossgen2-coreclr community-contribution Indicates that the PR has been added by a community member labels Sep 30, 2022
@ghost
Copy link

ghost commented Sep 30, 2022

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

Issue Details

Also delete the (now-unused) internal CommandLine implementation.

Author: am11
Assignees: -
Labels:

area-Infrastructure-coreclr, community-contribution

Milestone: -

Co-authored-by: Jakob Botsch Nielsen <[email protected]>
@am11 am11 requested a review from jkotas October 1, 2022 20:09
Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. @jakobbotsch Any other feedback?

mibcReaders[i] = MIbcProfileParser.OpenMibcAsPEReader(commandLineOptions.InputFilesToMerge[i].FullName);
string path = paths.ElementAt(i).Value;
PrintMessage($"Opening {path}");
mibcReaders[i] = MIbcProfileParser.OpenMibcAsPEReader(path);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The switch to Dictionary for references and the input .mibc files is concerning to me. It introduces non-determinism into the tool since these are enumerated. It seems like we should have a variant that expands into a List instead.

The fact that ilc/crossgen2 have the same problem for --input-file-path is a little concerning to me too, but I can see that it is preexisting to your changes.

Copy link
Member Author

@am11 am11 Oct 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakobbotsch, in the existing implementation, we are using the same AppendExpandedPaths helper in:

List<FileInfo> DefineFileOptionList(string name, string help)

although it returns a list, the result is equally non-deterministic (across multiple executions with same 'path patterns' arguments), due to the usage of Dictionary internally.

Note that we are (and were) using the same helper in ilc, crossgen2, ilverify and pgo.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't call it equally non-deterministic. In the common case without patterns the dictionaries have just one entry for each specified path and thus the existing version ends up being deterministic. This is for instance the case in our internal uses of dotnet-pgo merge in our training scenarios. There we are calling dotnet-pgo merge with a bunch of exact file names. The order was deterministic before but is going to be non-deterministic after this change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AppendExpandedPaths always uses dictionary.Add(simpleName, fullFileName) even for the exact file names.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but DefineFileOptionList is creating a new dictionary for each path. Each dictionary ends up having only one entry and the list returned ends with the same order as the order given in the input.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. In ilc and crossgen2, we were passing the same dictionary instance to the helper before

foreach (var input in _commandLineOptions.InputFilePaths)
Helpers.AppendExpandedPaths(_inputFilePaths, input, true);
so the new (BuildPathDictionary) helper didn't change the behavior. Pgo is creating a new dictionary for each pattern, which is better.

BTW, this globbing implementation does not support patterns like /path/**/*.mbic, given: /path/1/foo.mbic and /path/2/foo.mbic, it will only give us /path/2/foo.mbic. The better approach would be to use something like MSBuildGlob from this package.

@jkotas jkotas merged commit 039ced5 into dotnet:main Oct 3, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Nov 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-coreclr community-contribution Indicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants