Hosting API to enable hot reload at startup

[lambdageek]

Related to #44806 and #45629.

When running without a debugger attached, we need a way to tell the runtime that certain assemblies will be modified with EnC deltas. For Mono we need to do this early enough that we set the right interpreter optimization flags before we execute any managed code from the affected assemblies.

The information given to the runtime should probably include the set of assemblies that will be modified (as opposed to informing the runtime that any assembly at all could potentially be modified).

The current proposal:

Pass an environment variable DOTNET_MODIFIABLE_ASSEMBLIES with the case-insensitive keyword "debug" to enable all debug built assemblies for hot reload. This can be expanded on with other keywords like "all" or a comma separated list of assemblies when there are clear scenarios for the options.

Alternative approaches:

1. Pass a new MODIFIABLE_ASSEMBLIES property to coreclr_initialize that includes a list of assemblies that the runtime should expect to be modified. The presence of the property would indicate that hot reload support should be enabled. We could pass the property via the .runtimeconfig.dev.json file without any modifications to the (desktop) host. Mobile and wasm workloads would need to adjust their hosts.
2. Pass an environment variable DOTNET_MODIFIABLE_ASSEMBLIES with the same information. On mobile and wasm workloads, the hosts wouldn't need to be adjusted, MonoVM would consult the environment variable itself. On other workloads the host could interpret the environment variable or leave it to the runtimes.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[lambdageek]

/cc @tommcdon @mikem8361 @jkotas @vargaz

Tagging subscribers to this area: @vitek-karas, @agocke
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Related to #44806 and #45629.

When running without a debugger attached, we need a way to tell the runtime that certain assemblies will be modified with EnC deltas. For Mono we need to do this early enough that we set the right interpreter optimization flags before we execute any managed code from the affected assemblies.

The information given to the runtime should probably include the set of assemblies that will be modified (as opposed to informing the runtime that any assembly at all could potentially be modified).

There are two approaches we could take:

1. Pass a new MODIFIABLE_ASSEMBLIES property to coreclr_initialize that includes a list of assemblies that the runtime should expect to be modified. The presence of the property would indicate that hot reload support should be enabled. This will require some changes to the host.
2. Pass an environment variable ComPlus_ModifiableAssemblies with the same information. This could be done used by tooling without altering the host.

My loosely held opinion is that an environment variable is better.

Author:	lambdageek
Assignees:	-
Labels:	api-suggestion, area-Host, untriaged
Milestone:	-

[jkotas]

My loosely held opinion is that an environment variable is better.

It assumes that the app in EnC mode is launched by a controller that sets this environment variable for you. Is it a safe assumption to make?

ComPlus_ModifiableAssemblies

DOTNET_MODIFIABLE_ASSEMBLIES would be a better name.

[vitek-karas]

Passing additional properties to the runtime through coreclr_initialize is already possible by modifying the .runtimeconfig.json or via .runtimeconfig.dev.json. Using those would not need any host changes. We could also add the env. variable support to the host for this and potentially even command line support if necessary.

In this sense it would be similar to DOTNET_STARTUP_HOOKS which is an env. variable read by the host and passed to the runtime via the runtime properties. For this one we only allow runtimeconfig and env. variable - there's no command line, at least yet.

I guess it depends on the needs in this case:

• Do we need to support something like "lazy attach", so that the app starts without the "controller" which "attaches" much later on?
• Do we need to support this on "random" app, that is app which was produced using any build configuration without knowing that it will be used this way?

If we only need to support this in cases where we build the app with hot reload in mind (similar to "Debug" configuration), then using the .runtimeconfig.dev.json and the runtime property would probably be a good fit - with no changes necessary to the host.

[lambdageek]

Hmm.. using .runtimeconfig.dev.json is appealing, but I don't think the content of that file is passed along to mobile (or wasm) workloads.

[vitek-karas]

Do we pass along the .runtimeconfig.json? That one would also work - if we're really doing a special build for this case.

[lambdageek]

Do we pass along the .runtimeconfig.json? That one would also work - if we're really doing a special build for this case.

My understanding is that at this time the mobile embedders don't bundle the json files (or otherwise make the content available). And also apparently they're not using monovm_initialize/coreclr_intialize yet.

I'm back to mildly preferring to use an environment variable.

Update: we added work items for XI and XA to make sure they call monovm_initialize dotnet/macios#10504 and dotnet/android#5537, although that still leaves the mobile hosts with funnelling the runtimeconfig properties into the runtime.

[lambdageek]

It assumes that the app in EnC mode is launched by a controller that sets this environment variable for you. Is it a safe assumption to make?

I think so. Hot Reload would most likely need a controller that is responsible for launching the app. (That seems the easiest way to guarantee that the controller has a consistent view of the source code, the managed assemblies and queued up EnC deltas)