JIT: Simplify JitDisasm matching behavior and support namespaces/generics in release #74430

jakobbotsch · 2022-08-23T14:33:44Z

This changes how the JIT matches method names and signatures for method
sets (e.g. JitDisasm). It also starts printing method instantiations for full method names
and makes references to types consistent in generic instantiations and the signature.

In addition it starts supporting generic instantiations in release too.

To do this, most of the type printing is moved to the JIT, which also aligns the output
between crossgen2 and the VM (there were subtle differences here, like spaces between generic type arguments).
More importantly, we (for the most part) stop relying on JIT-EE methods that are documented to only be for debug purposes.

The new behavior of the matching is the following:

The matching behavior is always string based.
The JitDisasm string is a space-separated list of patterns. Patterns can arbitrarily
contain both '*' (match any characters) and '?' (match any 1 character).
The string matched against depends on characters in the pattern:
- If the pattern contains a ':' character, the string matched against is prefixed by the class name and a colon
- If the pattern contains a '(' character, the string matched against is suffixed by the signature
- If the class name (part before colon) contains a '[', the class contains its generic instantiation
- If the method name (part between colon and '(') contains a '[', the method contains its generic instantiation

For example, consider

namespace MyNamespace
{
    public class C<T1, T2>
    {
        [MethodImpl(MethodImplOptions.NoInlining)]
        public void M<T3, T4>(T1 arg1, T2 arg2, T3 arg3, T4 arg4)
        {
        }
    }
}

new C<sbyte, string>().M<int, object>(default, default, default, default); // compilation 1
new C<int, int>().M<int, int>(default, default, default, default); // compilation 2

The full strings are:
Before:

MyNamespace.C`2[SByte,__Canon][System.SByte,System.__Canon]:M(byte,System.__Canon,int,System.__Canon)
MyNamespace.C`2[Int32,Int32][System.Int32,System.Int32]:M(int,int,int,int)

Notice no method instantiation and the double class instantiation, which seems like an EE bug. Also two different names are used for sbyte: System.SByte and byte.

After the change the strings are:

MyNamespace.C`2[byte,System.__Canon]:M[int,System.__Canon](byte,System.__Canon,int,System.__Canon)
MyNamespace.C`2[int,int]:M[int,int](int,int,int,int)

The following strings will match both compilations:

M
*C`2:M
*C`2[*]:M[*](*)
MyNamespace.C`2:M

The following will match only the first one:

M[int,*Canon]
MyNamespace.C`2[byte,*]:M
M(*Canon)

There is one significant change in behavior here, which is that I have removed the special case that allows matching class names without namespaces. In particular, today Console:WriteLine would match all overloads of System.Console.WriteLine, while after this change it will not match. However, with generalized wild cards the replacement is simple in *Console:WriteLine.

This changes how the JIT matches method names and signatures for method sets (e.g. JitDisasm). The new behavior is the following: * The matching behavior is always string based. * The JitDisasm string is a space-separated list of patterns. Patterns can be quoted if they need to include spaces, and can arbitrarily contain both * (match any characters) and ? (match any 1 character). * If the pattern contains a : character, the string matched against is prefixed by "ClassName:". * If the pattern contains a ( character then the string matched against ends with its signature in the usual format. * Type names do not include namespaces. * The signature matched against does not contain return types or "is-instance" specifiers. For example, *:WriteLine is equivalent to WriteLine and will match all methods named WriteLine. Console:WriteLine will match all overloads of WriteLine defined in a class called Console. Console:WriteLine(String) and WriteLine(String) will match only the string overload.

ghost · 2022-08-23T14:34:01Z

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

Issue Details

This changes how the JIT matches method names and signatures for method
sets (e.g. JitDisasm). The new behavior is the following:

The matching behavior is always string based.
The JitDisasm string is a space-separated list of patterns. Patterns
can be quoted if they need to include spaces, and can arbitrarily
contain both * (match any characters) and ? (match any 1 character).
If the pattern contains a : character, the string matched against is
prefixed by "ClassName:".
If the pattern contains a ( character then the string matched against
ends with its signature in the usual format.
Type names do not include namespaces (might change this, the EE side is not giving us the namespace in release builds)
The signature matched against does not contain return types or
"is-instance" specifiers.

For example, *:WriteLine is equivalent to WriteLine and will match all
methods named WriteLine. Console:WriteLine will match all overloads of
WriteLine defined in a class called Console. Console:WriteLine(String)
and WriteLine(String) will match only the string overload. Overall, the string
you get at the top of JitDisasm and in JitDisasmSummary is exactly the
string we are matching against now (minus the return type suffix).

Author:	jakobbotsch
Assignees:	jakobbotsch
Labels:	`area-CodeGen-coreclr`
Milestone:	-

jakobbotsch · 2022-08-23T14:39:00Z

@dotnet/jit-contrib, any concerns about this change in behavior of the matching?
Also cc @stephentoub

jakobbotsch · 2022-08-23T14:41:07Z

src/coreclr/jit/jitconfig.cpp

-    int numArgs = sigInfo != nullptr ? sigInfo->numArgs : -1;
+    // names[hasClassName][hasSignature]
+    char*     names[2][2] = {};
+    Compiler* comp        = JitTls::GetCompiler();


Are we worried about this? It should be a single call in release builds and only when JitDisasm is non-empty.
We need it to allocate memory in rare cases where the string we are matching against is longer than 1024 characters.

…-string-match

docs/design/coreclr/jit/viewing-jit-dumps.md

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

BruceForstall · 2022-08-24T18:21:02Z

any concerns about this change in behavior of the matching?

Can you give examples of the change in behavior? It's not clear to me from the description, with the exception of supporting matching arguments, which is a great improvement.

If the pattern contains a : character, the string matched against is prefixed by "ClassName:".

What about the ":return_type" and ":this" suffixes we currently use?

docs/design/coreclr/jit/viewing-jit-dumps.md

jakobbotsch · 2022-08-24T18:41:28Z

Can you give examples of the change in behavior? It's not clear to me from the description, with the exception of supporting matching arguments, which is a great improvement.

To be honest it is not clear to me what the full extent of the existing parser's behavior is. One difference is that it allows ClassName::MethodName (two colons) -- we now only allow one colon. As you say, another one is in the matching of parameters. A final one is the treatment of wildcards, which I never really understood.

At least the way I normally have used method sets (ClassName:MethodName and MethodName, the occassional *) the behavior should not have changed, but I'm not sure if other people on the team are using some more advanced features.

What about the ":return_type" and ":this" suffixes we currently use?

It is not included as part of the signature that the matching works against.

MichalPetryka · 2022-08-24T20:00:00Z

Do those changes allow the filter to be used with generic types and methods?

jakobbotsch · 2022-08-25T08:34:59Z

Do those changes allow the filter to be used with generic types and methods?

Not in release builds. It probably needs some work on the JIT-EE interface so it won't happen as part of this change.

Like signatures, format the instantiations in the JIT so we get consistent type names in the entire string.

… file

While there as a comment that this is expensive, in my measuring of crossgenning SPC I could not see any performance difference.

jakobbotsch · 2022-09-02T09:31:17Z

src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

+            if (method.Instantiation.Length != 0)
+            {
+                sig->sigInst.methInst = GetJitInstantiation(method.Instantiation);
+            }


I have moved this out of the method.IsIntrinsic path to unconditionally fill it, since it is used by JIT for JitDisasm now and making assumptions on the exact scenarios this is used by the JIT is a bit icky.

If we are worried about performance (I did not see any measurable difference in crossgen2 times of SPC) then I think we should remove CORINFO_SIG_INFO::sigInst and put this on the same plan as ICorStaticInfo::getTypeInstantiationArgument. But I think we can wait and see the crossgen2 TP graphs in PowerBI.

…-string-match

This was completely ignoring the index.

jakobbotsch · 2022-09-02T16:06:21Z

src/coreclr/tools/superpmi/superpmi-shared/methodcontext.cpp

 void MethodContext::recGetTypeInstantiationArgument(CORINFO_CLASS_HANDLE cls,
-                                                    CORINFO_CLASS_HANDLE result,
-                                                    unsigned             index)
+                                                    unsigned             index,
+                                                    CORINFO_CLASS_HANDLE result)
 {
    if (GetTypeInstantiationArgument == nullptr)
-        GetTypeInstantiationArgument = new LightWeightMap<DWORDLONG, DWORDLONG>();
+        GetTypeInstantiationArgument = new LightWeightMap<DLD, DWORDLONG>();

-    DWORDLONG key = CastHandle(cls);
+    DLD key;
+    ZeroMemory(&key, sizeof(key));
+    key.A = CastHandle(cls);
+    key.B = index;
    DWORDLONG value = CastHandle(result);
    GetTypeInstantiationArgument->Add(key, value);
    DEBUG_REC(dmpGetTypeInstantiationArgument(key, value));
 }
-void MethodContext::dmpGetTypeInstantiationArgument(DWORDLONG key, DWORDLONG value)
+void MethodContext::dmpGetTypeInstantiationArgument(DLD key, DWORDLONG value)
 {
-    printf("GetTypeInstantiationArgument key - classNonNull-%llu, value NonNull-%llu", key, value);
+    printf("GetTypeInstantiationArgument key - classNonNull-%llu, index-%u, value NonNull-%llu", key.A, key.B, value);
    GetTypeInstantiationArgument->Unlock();
 }
 CORINFO_CLASS_HANDLE MethodContext::repGetTypeInstantiationArgument(CORINFO_CLASS_HANDLE cls, unsigned index)
 {
    CORINFO_CLASS_HANDLE result = nullptr;

-    DWORDLONG key = CastHandle(cls);
+    DLD key;
+    ZeroMemory(&key, sizeof(key));
+    key.A = CastHandle(cls);
+    key.B = index;


@BruceForstall annoyingly, I suppose this bug fix means I should bump the JIT-EE GUID in this change even though there are no changes to the JIT-EE interface.

True; any time the SPMI binary format changes, we also need a JIT-EE GUID change.

jakobbotsch · 2022-09-02T20:16:29Z

@dotnet/jit-contrib This should be ready now. I have updated the original text of the PR, so please read it and give me your thoughts on that. This behavior change probably being the largest thing:

There is one significant change in behavior here, which is that I have removed the special case that allows matching class names without namespaces. In particular, today Console:WriteLine would match all overloads of System.Console.WriteLine, while after this change it will not match. However, with generalized wild cards the replacement is simple in *Console:WriteLine.

It would be nice to get a review on this today so I can hopefully merge this on the weekend and avoid disruption due to the JIT-EE GUID change.

jakobbotsch · 2022-09-02T20:19:54Z

src/coreclr/jit/jitconfigvalues.h

-CONFIG_INTEGER(JitDumpTier0, W("JitDumpTier0"), 1)                     // Dump tier0 requests
-CONFIG_INTEGER(JitDumpAtOSROffset, W("JitDumpAtOSROffset"), -1)        // Only dump OSR requests for this offset
-CONFIG_INTEGER(JitDumpInlinePhases, W("JitDumpInlinePhases"), 1)       // Dump inline compiler phases
+CONFIG_INTEGER(JitDisasmSpilled, W("JitDisasmSpilled"), 0)      // Display native code when any register spilling occurs


This was shoehorned into JitDisasm by specifying "SPILLED" before. I have introduced a separate variable for it instead.

BruceForstall

This looks really great!

I only pointed out a couple nits, but feel free to ignore.

src/coreclr/inc/corinfo.h

docs/design/coreclr/jit/viewing-jit-dumps.md

Co-authored-by: Bruce Forstall <brucefo@microsoft.com>

jakobbotsch · 2022-09-04T15:56:19Z

superpmi failures are expected due to the JIT-EE GUID change.

jakobbotsch · 2022-09-08T10:59:54Z

/backport to release/7.0

github-actions · 2022-09-08T11:00:08Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3014516413

github-actions · 2022-09-08T11:02:00Z

@jakobbotsch backporting to release/7.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: Remove SPILLED JitDisasm in favor of JitDisasmSpilled
Applying: JIT: Simplify MethodSet matching behavior
error: sha1 information is lacking or useless (src/coreclr/jit/compiler.cpp).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 JIT: Simplify MethodSet matching behavior
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

This changes how the JIT matches method names and signatures for method sets (e.g. JitDisasm). It also starts printing method instantiations for full method names and makes references to types consistent in generic instantiations and the signature. In addition it starts supporting generic instantiations in release too. To do this, most of the type printing is moved to the JIT, which also aligns the output between crossgen2 and the VM (there were subtle differences here, like spaces between generic type arguments). More importantly, we (for the most part) stop relying on JIT-EE methods that are documented to only be for debug purposes. The new behavior of the matching is the following: * The matching behavior is always string based. * The JitDisasm string is a space-separated list of patterns. Patterns can arbitrarily contain both '*' (match any characters) and '?' (match any 1 character). * The string matched against depends on characters in the pattern: + If the pattern contains a ':' character, the string matched against is prefixed by the class name and a colon + If the pattern contains a '(' character, the string matched against is suffixed by the signature + If the class name (part before colon) contains a '[', the class contains its generic instantiation + If the method name (part between colon and '(') contains a '[', the method contains its generic instantiation For example, consider ``` namespace MyNamespace { public class C<T1, T2> { [MethodImpl(MethodImplOptions.NoInlining)] public void M<T3, T4>(T1 arg1, T2 arg2, T3 arg3, T4 arg4) { } } } new C<sbyte, string>().M<int, object>(default, default, default, default); // compilation 1 new C<int, int>().M<int, int>(default, default, default, default); // compilation 2 ``` The full strings are: Before the change: ``` MyNamespace.C`2[SByte,__Canon][System.SByte,System.__Canon]:M(byte,System.__Canon,int,System.__Canon) MyNamespace.C`2[Int32,Int32][System.Int32,System.Int32]:M(int,int,int,int) ``` Notice no method instantiation and the double class instantiation, which seems like an EE bug. Also two different names are used for sbyte: System.SByte and byte. After the change the strings are: ``` MyNamespace.C`2[byte,System.__Canon]:M[int,System.__Canon](byte,System.__Canon,int,System.__Canon) MyNamespace.C`2[int,int]:M[int,int](int,int,int,int) ``` The following strings will match both compilations: ``` M *C`2:M *C`2[*]:M[*](*) MyNamespace.C`2:M ``` The following will match only the first one: ``` M[int,*Canon] MyNamespace.C`2[byte,*]:M M(*Canon) ``` There is one significant change in behavior here, which is that I have removed the special case that allows matching class names without namespaces. In particular, today Console:WriteLine would match all overloads of System.Console.WriteLine, while after this change it will not match. However, with generalized wild cards the replacement is simple in *Console:WriteLine.

…amespaces/generics in release (#75260) * JIT: Simplify JitDisasm matching behavior (#74430) This changes how the JIT matches method names and signatures for method sets (e.g. JitDisasm). It also starts printing method instantiations for full method names and makes references to types consistent in generic instantiations and the signature. In addition it starts supporting generic instantiations in release too. To do this, most of the type printing is moved to the JIT, which also aligns the output between crossgen2 and the VM (there were subtle differences here, like spaces between generic type arguments). More importantly, we (for the most part) stop relying on JIT-EE methods that are documented to only be for debug purposes. The new behavior of the matching is the following: * The matching behavior is always string based. * The JitDisasm string is a space-separated list of patterns. Patterns can arbitrarily contain both '*' (match any characters) and '?' (match any 1 character). * The string matched against depends on characters in the pattern: + If the pattern contains a ':' character, the string matched against is prefixed by the class name and a colon + If the pattern contains a '(' character, the string matched against is suffixed by the signature + If the class name (part before colon) contains a '[', the class contains its generic instantiation + If the method name (part between colon and '(') contains a '[', the method contains its generic instantiation For example, consider ``` namespace MyNamespace { public class C<T1, T2> { [MethodImpl(MethodImplOptions.NoInlining)] public void M<T3, T4>(T1 arg1, T2 arg2, T3 arg3, T4 arg4) { } } } new C<sbyte, string>().M<int, object>(default, default, default, default); // compilation 1 new C<int, int>().M<int, int>(default, default, default, default); // compilation 2 ``` The full strings are: Before the change: ``` MyNamespace.C`2[SByte,__Canon][System.SByte,System.__Canon]:M(byte,System.__Canon,int,System.__Canon) MyNamespace.C`2[Int32,Int32][System.Int32,System.Int32]:M(int,int,int,int) ``` Notice no method instantiation and the double class instantiation, which seems like an EE bug. Also two different names are used for sbyte: System.SByte and byte. After the change the strings are: ``` MyNamespace.C`2[byte,System.__Canon]:M[int,System.__Canon](byte,System.__Canon,int,System.__Canon) MyNamespace.C`2[int,int]:M[int,int](int,int,int,int) ``` The following strings will match both compilations: ``` M *C`2:M *C`2[*]:M[*](*) MyNamespace.C`2:M ``` The following will match only the first one: ``` M[int,*Canon] MyNamespace.C`2[byte,*]:M M(*Canon) ``` There is one significant change in behavior here, which is that I have removed the special case that allows matching class names without namespaces. In particular, today Console:WriteLine would match all overloads of System.Console.WriteLine, while after this change it will not match. However, with generalized wild cards the replacement is simple in *Console:WriteLine. * Update JIT-EE GUID Avoid using the same JIT-EE GUID as the main branch.

jakobbotsch added 2 commits August 23, 2022 13:16

Remove SPILLED JitDisasm in favor of JitDisasmSpilled

51b978d

dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Aug 23, 2022

ghost assigned jakobbotsch Aug 23, 2022

jakobbotsch commented Aug 23, 2022

View reviewed changes

jakobbotsch added 2 commits August 23, 2022 17:11

Update docs, minor nits

efdc84a

Merge branch 'main' of github.com:dotnet/runtime into jit-method-name…

a2af04b

…-string-match

AaronRobinsonMSFT reviewed Aug 24, 2022

View reviewed changes

docs/design/coreclr/jit/viewing-jit-dumps.md Outdated Show resolved Hide resolved

docs/design/coreclr/jit/viewing-jit-dumps.md Outdated Show resolved Hide resolved

docs/design/coreclr/jit/viewing-jit-dumps.md Show resolved Hide resolved

Apply suggestions from code review

dc67a40

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

BruceForstall reviewed Aug 24, 2022

View reviewed changes

docs/design/coreclr/jit/viewing-jit-dumps.md Outdated Show resolved Hide resolved

jakobbotsch and others added 2 commits August 25, 2022 11:15

Update docs/design/coreclr/jit/viewing-jit-dumps.md

03a1fa7

Use appendClassName to get namespaces and generic instantiations

4ded1a9

runfoapp bot mentioned this pull request Aug 31, 2022

Test_EventSource_EtwManifestGeneration* tests failing in CI #48798

Closed

jakobbotsch added 11 commits September 1, 2022 15:24

Format instantiations in JIT

4dcce2a

Like signatures, format the instantiations in the JIT so we get consistent type names in the entire string.

Minor adjustments

510e5ec

Add method instantiations

da27ae0

Update docs

55693f3

Go back to square brackets

e9e6e06

Congruence

daf08e4

Single quotes

633fa76

Add some SPMI error traps

2764293

Switch vsnprintf_s -> _vsnprintf_s, move StringPrinter::Printf to cpp…

0748742

… file

Another compilation fix

5de9b29

Change crossgen2/ILC to fill in instantiations always

98eee9f

While there as a comment that this is expensive, in my measuring of crossgenning SPC I could not see any performance difference.

jakobbotsch commented Sep 2, 2022

View reviewed changes

jakobbotsch added 6 commits September 2, 2022 13:01

Fix a couple more angle brackets, add some braces to single line ifs

bebe9f4

Make globbing quadratic instead of exponential

0cf37d7

Use asCorInfoType instead of getTypeForPrimitiveValueClass

68dfcda

Run jit-format

a94ac52

Merge branch 'main' of github.com:dotnet/runtime into jit-method-name…

b0d00ac

…-string-match

SPMI: Fix getTypeInstantiationArgument

a3f01e9

This was completely ignoring the index.

jakobbotsch commented Sep 2, 2022

View reviewed changes

jakobbotsch added 2 commits September 2, 2022 21:42

Bump JIT-EE GUID

ae673c1

Add header comments, rename some parameters

a8737b3

jakobbotsch commented Sep 2, 2022

View reviewed changes

jakobbotsch marked this pull request as ready for review September 2, 2022 20:26

jakobbotsch requested a review from MichalStrehovsky as a code owner September 2, 2022 20:26

BruceForstall approved these changes Sep 2, 2022

View reviewed changes

src/coreclr/inc/corinfo.h Outdated Show resolved Hide resolved

docs/design/coreclr/jit/viewing-jit-dumps.md Outdated Show resolved Hide resolved

Apply suggestions from code review

4507256

Co-authored-by: Bruce Forstall <brucefo@microsoft.com>

jakobbotsch merged commit 243cf9f into dotnet:main Sep 4, 2022

jakobbotsch deleted the jit-method-name-string-match branch September 4, 2022 15:58

jakobbotsch changed the title ~~JIT: Simplify JitDisasm matching behavior~~ JIT: Simplify JitDisasm matching behavior and support namespaces/generics in release Sep 7, 2022

jakobbotsch mentioned this pull request Sep 8, 2022

[release/7.0] JIT: Simplify JitDisasm matching behavior and support namespaces/generics in release #75260

Merged

ghost locked as resolved and limited conversation to collaborators Oct 8, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JIT: Simplify JitDisasm matching behavior and support namespaces/generics in release #74430

JIT: Simplify JitDisasm matching behavior and support namespaces/generics in release #74430

jakobbotsch commented Aug 23, 2022 •

edited

Loading

ghost commented Aug 23, 2022

jakobbotsch commented Aug 23, 2022

jakobbotsch Aug 23, 2022

BruceForstall commented Aug 24, 2022

jakobbotsch commented Aug 24, 2022 •

edited

Loading

MichalPetryka commented Aug 24, 2022 •

edited

Loading

jakobbotsch commented Aug 25, 2022

jakobbotsch Sep 2, 2022

jakobbotsch Sep 2, 2022

BruceForstall Sep 2, 2022

jakobbotsch commented Sep 2, 2022

jakobbotsch Sep 2, 2022

BruceForstall left a comment

jakobbotsch commented Sep 4, 2022

jakobbotsch commented Sep 8, 2022

github-actions bot commented Sep 8, 2022

github-actions bot commented Sep 8, 2022

JIT: Simplify JitDisasm matching behavior and support namespaces/generics in release #74430

JIT: Simplify JitDisasm matching behavior and support namespaces/generics in release #74430

Conversation

jakobbotsch commented Aug 23, 2022 • edited Loading

ghost commented Aug 23, 2022

jakobbotsch commented Aug 23, 2022

jakobbotsch Aug 23, 2022

Choose a reason for hiding this comment

BruceForstall commented Aug 24, 2022

jakobbotsch commented Aug 24, 2022 • edited Loading

MichalPetryka commented Aug 24, 2022 • edited Loading

jakobbotsch commented Aug 25, 2022

jakobbotsch Sep 2, 2022

Choose a reason for hiding this comment

jakobbotsch Sep 2, 2022

Choose a reason for hiding this comment

BruceForstall Sep 2, 2022

Choose a reason for hiding this comment

jakobbotsch commented Sep 2, 2022

jakobbotsch Sep 2, 2022

Choose a reason for hiding this comment

BruceForstall left a comment

Choose a reason for hiding this comment

jakobbotsch commented Sep 4, 2022

jakobbotsch commented Sep 8, 2022

github-actions bot commented Sep 8, 2022

github-actions bot commented Sep 8, 2022

jakobbotsch commented Aug 23, 2022 •

edited

Loading

jakobbotsch commented Aug 24, 2022 •

edited

Loading

MichalPetryka commented Aug 24, 2022 •

edited

Loading