The Unity Engine roadmap - Unite 2025

[RichardFine]

@meredoth

1. Although not directly related to CoreCLR The IL produced by modern .NET versions is optimized, so the C++ code produced will be better too, of course that’s just a speculation as better IL doesn’t necessarily mean better C++ code produced, but I don’t know about the internal implementation of IL2CPP.

Most of that is a function of the compiler, not the runtime. We can (and will) upgrade the compiler without needing to wait for the CoreCLR runtime to be integrated. Some things, like support for hardware intrinsics, will depend on both CoreCLR and IL2CPP being ready for them.

2. The garbage collector used by CoreCLR will also be statically linked to any AOT compilation, so the benefits of the new GC will also benefit IL2CPP builds, considering of course that IL2CPP will be using the CoreCLR GC and not the Boehm one.

No - AOT for IL2CPP is completely independent of AOT for CoreCLR (which we have no plans to adopt anyway). GC behaviour on IL2CPP improves when we upgrade the GC there, it’s not really affected by CoreCLR at all.

3. The low level libraries that are part of the CoreCLR also have optimizations that may transfer to the code produced by IL2CPP, “may” is the keyword here as again I don’t know anything about the internals of the IL2CPP.

As we migrate IL2CPP from using the Mono BCL to using the .NET BCL, there may indeed be performance improvements, though these would be quite specific/targeted to things where the .NET BCL came up with a better way of doing things than the Mono BCL.