Closed swaroop-sridhar closed 4 years ago
Checked in GcInfo Versioning: https://github.com/dotnet/coreclr/commit/0d5eac078847baebb32653655373086d6729f923
Checked in some clean up to facilitate new GcInfo version: https://github.com/dotnet/coreclr/commit/d1697c6f8b6e6d1f06b4d734fabd3b328e1dc724
Implemented new GcInfo v2 for RYU encoding, under testing.
We currently cannot do GCStress after direct calls on native images because the GCInfo for the type is not encoded in the GCInfo.
@jkotas wrote: "The fundamental problem is that the method return hijacking has to run type loader to figure out GC-ness of method return type. Running type loader (ie a ton of random code) during GC is very delicate and bug-prone endeavor. Recording GC-ness of method return type in GCInfo makes it simple and robust.It would be overall goodness.
(BTW: This would also get us closer to how ProjectN works and help CoreRT - recording GC-ness of return type is one the CoreRT RyuJIT codegen workitems.)"