Resolved Burst compatible by default for most of the unity engine APIs and packages

The problem with this approach is that the restriction Burst imposes (no managed objects at all), is making the design of API extremally laborious and sometimes impractical. We had even some folks asking for Burst to add support for e.g reference counting, or virtual tables (so class inheritance almost) or catchable exceptions... exactly what a managed .NET runtime is supposed to provide. It is a path that has been causing lots of trouble for our users and internal developers. For example it makes it impossible to use regular .NET API for very basic stuffs (strings, network, HTTP...etc!) and discarding an entire part of the .NET ecosystem that we can't rely on. It would be a mistake to pursue this approach, as it would fragment the Unity ecosystem further.

But the good news is that we are thinking to solve this problem the other way around!

With CoreCLR coming to Unity, performance is going to be significantly improved, but also we would like to take a different approach in the future: as we entertained at some point about "performance by default", we should provide this performance by default for the entire .NET, not a small subset of it. And so, we would like to bridge the gap between Burst and .NET CoreCLR so that you won't have to care about if things are running with Burst or not, potentially the idea of using Burst as a tiered compilation for CoreCLR... or even further, to support the full .NET framework/runtime with Burst, while keeping the compatibility with CoreCLR.

 

For an explanation of tiered compilation, you can find more details here (I'm not sure if it is the core part of your question).
Then for Burst participating to tiered compilation, the idea would be to plug it in CoreCLR JIT so that Burst could be triggered as an additional compilation optimization on user code (Tiered 3), while CoreCLR would handle Tiered 0 (not optimized) and Tiered 1 (optimized).

We had an internal prototype working so it is a promising approach.

Yes, so that Burst would support Managed Objects as well. We can't tell more about it, as it is something that we haven't plan for or even discussed technically about what it will require. It is also evolving rapidly, as CoreCLR has been improving massively over the past years, it might not be necessary to have Burst to support the full .NET BCL if e.g CoreCLR is good enough for 90% of the user performance cases. But It is also several years in the future. We are focusing on bringing CoreCLR for now, one step at a time!

 

Indeed, you are definitely right to say that somehow, what we have today is already close to a tiered compilation.

The difference is that today, this "transparent" process is requiring a slow IL postprocessing and is requiring to tag your code explicitly with [BurstCompile]. Once a method is tagged, there is a runtime overhead to have a method tagged by this (we need to be able to switch to manage code if Burst is disabled) and it is complicating the plugin of this feature (we need to generate a trampoline method to go Burst native code). So the idea would be to plug Burst native code differently, at the core of CoreCLR JIT/AOT code generation.

With an integrated approach with CoreCLR, we might keep an attribute like BurstCompile to ensure that e.g this would always compile with Burst, but otherwise, this would be entirely transparent.