Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPAOT - re-enable vtable calls within CoreLib #7168

Open
trylek opened this Issue Mar 14, 2019 · 3 comments

Comments

3 participants
@trylek
Copy link
Contributor

trylek commented Mar 14, 2019

We need to temporarily disable the optimization regarding vtable calls in CoreLib because it requires either re-implementing the CoreCLR method table builder in CPAOT or persisting the vtable layouts in the R2R image. Neither technology exists today. We however need to re-enable this optimization before shipping because the optimization is important for CoreLib performance and needed for letting us publish R2R (instead of fragile NGEN) CoreLib.

The bit of code I am commenting out is in ceeInfoGetCallInfo in CorInfoImpl.ReadyToRun.cs around line 1070 under the conditional clause

if (MethodInSystemVersionBubble(callerMethod) && MethodInSystemVersionBubble(targetMethod))

@trylek trylek added this to To do in .NET Core 3.0 Ready To Run via automation Mar 14, 2019

@jkotas

This comment has been minimized.

Copy link
Member

jkotas commented Mar 14, 2019

optimization is important for CoreLib performance

Unclear how important it is. We have done in crossgen because of it was easy to do, not because of it was important.

@trylek

This comment has been minimized.

Copy link
Contributor Author

trylek commented Mar 14, 2019

I can ask @fadimounir for advice and run some perf testing with the optimization disabled in CoreCLR so that we get an idea. I understood Simon @nattress' response so that the optimization is crucial for letting us ship R2R-compiled CoreLib but I may have misunderstood him or he may have been mistaken about this.

@fadimounir

This comment has been minimized.

Copy link
Member

fadimounir commented Mar 14, 2019

There's another change that I merged after that vtable optimization in CoreLib, and that other change optimizes vtable calls for all cases, not just corelib. See dotnet/coreclr#20696.
It's slightly less efficient than the optimization for Corelib since it requires the creation of a small vtable-call stub at runtime, and the cost of the extra call to that stub, but the codegen in it is equivalent to what we would have had for corelib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.