Resolved Domain reload in Editor

Hello OndrejP,

We are as well, and it is quite a challenging topic.

We are in the early design phase. What we know so far is that the new design will be a breaking change, requiring a cooperative approach with user code.

Today, even if a small amount of code is changed, the editor will have to shutdown the entire AppDomain, save all states, create a new AppDomain, reload all states, reload all assemblies, and rerun all user code (with JIT codegen being rerun on all user and engine code). The problem is that over time, we have been using more and more C# code (internally in Unity, but also our users as well), and so we have almost 5x times more code to JIT/reload today then we had when the current "Domain Reload" approach was implemented 10 years+ ago. We know that is approach doesn't scale anymore, to say the least and is one of the major reason slowing down the iteration time and a frustration for everybody.

What we would like to change is really around the idea of "pay for what is changed, no more". What it means is that we won't do a domain reload anymore but we will follow a more cooperative "code reload" and "data reload" approach.

Technically, we will most likely use Assembly Load Context(ALC). Ideally, we would like to group assemblies into islands of ALC that have clear macro dependencies so that we will be able to unload only parts of the code that has been changed, so that the whole reload process would be more incremental.

What we mean by cooperative is that your code will have to change (e.g register to some events) in order to correctly handle shutdown/reinit (stopping threads running, static variables to re-initialize...etc.).

In the medium term, with hope to leverage also the "Edit and Continue" feature of CoreCLR that would allow to patch IL/native code without having to reload code or data entirely. This feature is usually more limited in the kind of changes it can handle, but if you iterate on the body of a function, it would be massively more efficient in terms of iteration time.

It is too early to say but we hope to provide the tooling (at compile time, at runtime), to inspect anything suspicious or inefficient regarding code reload.

This should be a lot more faster. I wouldn't be surprised that we could achieve an order of magnitude faster on very large projects, not necessarily in our first version of the new system, but we will see. We have still quite some unknowns to confirm that expectation.

You were spot on with your questions. For example, how to detect if user code is compatible with this new code reload or that something is not reloading while it should? How to minimize the amount of code we need to unload/reload? If some data is dependent on some code (a class/struct), how do we know what to reload? What happens with mutable static variables, events?...

We are still in the early phase of design, so we don't have necessarily a precise answers for all these questions but we are starting to have a better idea of the problem space.

 

Indeed, It will be a hard break. We won't be able to maintain the old and the new unfortunately. On the bright side, by doing so, we should be able to bring more massive C# code iteration improvement and be more opportunistic about these optimizations.

 

If you project has been relying on Fast Enter Play mode (FEP as we call it internally) or you have been using DOTS, it will definitely help! We don't know yet if it will require more modifications, at least likely internally in DOTS.