Skip to content

Improve likely class handling for pgo#51284

Merged
davidwrighton merged 9 commits into
dotnet:mainfrom
davidwrighton:improveLikelyClassHandling
Apr 16, 2021
Merged

Improve likely class handling for pgo#51284
davidwrighton merged 9 commits into
dotnet:mainfrom
davidwrighton:improveLikelyClassHandling

Conversation

@davidwrighton

Copy link
Copy Markdown
Member
  • Move processing of likely class histogram into the JIT
  • Fix cases where the devirtualization logic in crossgen2 behaved incorrectly in the presence of likely class histogram data
  • Pre-process histogram at crossgen2 time to reduce the size of the pgo data
    • This removes 3/4 of the data from System.Private.CoreLib

Areas where I would particularly like to see comments

  • The process by which crossgen2 calls into the JIT for preprocessing the type histogram. Currently its done via a free function exported from the jit dll, which isn't particularly clean. I'd like ideas on how to clean that up, or an agreement that its... ok.

@ghost ghost added the area-ReadyToRun label Apr 14, 2021
@davidwrighton

Copy link
Copy Markdown
Member Author

@dotnet/crossgen-contrib @dotnet/jit-contrib

}
else
{
int currentObjectIndex = 0x1000000;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

should this be defined as a constant?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Eh, the value is only used one place, and really just needs to be a large non-zero number. I'll leave a comment instead.

@mangod9

mangod9 commented Apr 15, 2021

Copy link
Copy Markdown
Member

LGTM from cg2 side.

@AndyAyersMS AndyAyersMS left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm ok with this approach of calling back into the jit. cc @BruceForstall in case he has any thoughts.

Seems like the histogram processing should be in some new file.

Do you know if this works properly for cross-bitness jitting? I am not sure how some of these types vary with target -- seems like INT_PTR might be tied to the host?

Comment thread src/coreclr/inc/corjit.h
uint8_t ** pInstrumentationData // OUT: `*pInstrumentationData` is set to the address of the instrumentation data.
) = 0;

// Get the likely implementing class for a virtual call or interface call made by ftnHnd

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Changing the Jit Interface requires an update to JITEEVersionIdentifier located in jiteeversionguid.h

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Oops, I thought I had done that.

@davidwrighton

Copy link
Copy Markdown
Member Author

@AndyAyersMS

Do you know if this works properly for cross-bitness jitting? I am not sure how some of these types vary with target -- seems like INT_PTR might be tied to the host?

INT_PTR is tied to the host, but that's ok for crossbitness jitting as the INT_PTR is simply the contract for JIT/VM communication for class types. For storage into the PE file there is a different format which is token based. (and sadly somewhat verbose, which is why the compressed representation here is quite important.)

if (classType != IntPtr.Zero)
{
TypeDesc type = (TypeDesc)handleToObject[classType];
if (compilationModuleGroup.VersionsWithType(type))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
if (compilationModuleGroup.VersionsWithType(type))
#if READYTORUN
if (compilationModuleGroup.VersionsWithType(type))
#endif

@AndyAyersMS AndyAyersMS left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We will likely want something like this for merging as well...

Comment thread src/coreclr/jit/likelyclass.cpp Outdated
XX Likely Class Processing XX
XX XX
XX Parses Pgo data to find the most likely class in use at a given XX
XX in a method. Used by both the JIT, and by crossgen XX

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
XX in a method. Used by both the JIT, and by crossgen XX
XX offset in a method. Used by both the JIT, and by crossgen. XX

maybe?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes. I'm not sure where the IL offset bit of my comment went... I certainly remember writing it. Thanks for noting this.

@davidwrighton

Copy link
Copy Markdown
Member Author

This should mostly address #45286

@BruceForstall

Copy link
Copy Markdown
Contributor

@davidwrighton I'm late to the party here...

The process by which crossgen2 calls into the JIT for preprocessing the type histogram. Currently its done via a free function exported from the jit dll, which isn't particularly clean. I'd like ideas on how to clean that up, or an agreement that its... ok.

Why can't it be on the JIT-EE interface?

@davidwrighton davidwrighton deleted the improveLikelyClassHandling branch April 20, 2021 17:48
@karelz karelz added this to the 6.0.0 milestone May 20, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jun 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants