-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider a hot reload feature switch for linking #51159
Comments
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. |
Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar, @tannergooding, @CoffeeFlux Issue DetailsWe are going to have a variety of places across the core libraries that use MetadataUpdateHandlerAttribute to react to hot reload updates. Some of these handlers will have zero impact unless used (other than their presence in the library binaries) while others will have additional code on "normal" execution code paths, e.g. to track things that later need to be cleared. We should look at either using an existing feature switch (e.g. Debugging.IsSupported) or a new feature switch (e.g. HotReload.IsSupported) that we tie all of these to and use to both link away and disable any expense when not required. We should aim to use the same switch across the whole stack (currently ASP.NET is using its own HotReload.IsSupported).
|
Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @tannergooding, @sbomer Issue DetailsWe are going to have a variety of places across the core libraries that use MetadataUpdateHandlerAttribute to react to hot reload updates. Some of these handlers will have zero impact unless used (other than their presence in the library binaries) while others will have additional code on "normal" execution code paths, e.g. to track things that later need to be cleared. We should look at either using an existing feature switch (e.g. Debugging.IsSupported) or a new feature switch (e.g. HotReload.IsSupported) that we tie all of these to and use to both link away and disable any expense when not required. We should aim to use the same switch across the whole stack (currently ASP.NET is using its own HotReload.IsSupported).
|
If I understand this correctly, would we be teaching the trimmer to remove all code paths inside a |
@lambdageek fyi |
If we added this switch, the trimmer would only remove code paths inside the There are other scenarios where the trimmer runs, but you still want to debug and hot-reload your app. One that comes to mind is Xamarin apps - See https://github.com/xamarin/xamarin-android/blob/main/Documentation/guides/OneDotNet.md#dotnet-build--publish. |
Is the logic fully detached from Debugging.IsSupported feature switch? In other words would settings like Debugging.IsSupported = false, HotReload.IsSupported = true work? |
* Use feature switch to perform hot reload trimming Contributes to dotnet/runtime#51159
* Use feature switch to perform hot reload trimming Contributes to dotnet/runtime#51159 * Clear caches from more places on a hot reload event * Rename variable for clarity Co-authored-by: Steve Sanderson <[email protected]>
Do we still plan on doing something targeted here? ASP.NET Core is currently using |
I think the need for a separate feature flag is a bit more acute with the ongoing componentization of Mono, workloads can decide whether to bundle hot reload support in some configurations or builds of the user's app. |
namespace System.Reflection.Metadata
{
public static class MetadataUpdater
{
public static void ApplyUpdate(Assembly assembly, ReadOnlySpan<byte> metadataDelta, ReadOnlySpan<byte> ilDelta, ReadOnlySpan<byte> pdbDelta);
public static bool IsSupported { get; }
}
} |
We would need to add one more related API: GetApplyUpdateCapabilities() and probably rename it to GetCapabilities(). It is currently internal so the tests and hot reload agent/Roslyn use reflection but maybe we should make it public. |
Yup, we discussed that, it was just left out of the summary. We landed on GetCapabilities(). We didn't discuss changing it to be public. We also talked about how we may want to stage this by first adding the new class and changing the existing one to just delegate to it but not yet remove it, wait until the rest of the components have been updated to use the new type, and only then delete the old one (but hopefully that cycle can happen relatively quickly, as we'd want to delete the old one soon-ish). |
The old APIs AssemblyExtensions.ApplyUpdate() and AssemblyExtensions.GetApplyUpdateCapabilities() will be removed after all the references to them have been changed to the new APIs. Add the new IsSupported API described in issue dotnet#51159. Change the tests to use the MetadataUpdater APIs.
…54590) Move the metadata update related APIs to the MetadataUpdater class The old APIs AssemblyExtensions.ApplyUpdate() and AssemblyExtensions.GetApplyUpdateCapabilities() will be removed after all the references to them have been changed to the new APIs. Add the new IsSupported API described in issue #51159. Change the tests to use the MetadataUpdater APIs. Fix the ApplyUpdate qcalls and icalls Add the ILLink substitutions for MetadataUpdater.IsSupported property Change the old APIs to call the new ones Update mono's MetadataUpdater.IsSupported property Update feature switch doc Fixed the argument checking in coreclr's MetadataUpdater.ApplyUpdate().
Background and Motivation
We are going to have a variety of places across the core libraries that use MetadataUpdateHandlerAttribute to react to hot reload updates. Some of these handlers will have zero impact unless used (other than their presence in the library binaries) while others will have additional code on "normal" execution code paths, e.g. to track things that later need to be cleared. We should look at either using an existing feature switch (e.g. Debugging.IsSupported) or a new feature switch (e.g. AssemblyExtensions.IsApplyUpdateAvailable) that we tie all of these to and use to both link away and disable any expense when not required. We should aim to use the same switch across the whole stack (currently ASP.NET is using its own property).
Proposed API
The .NET Core runtime will basically implement like this (and will cache the value in a static):
The feature switch support in the runtime build files include this property so the conditional apply update code is elided on release builds.
Usage Examples
The hot reload agent can use this to ensure that it can actually apply updates to the application. Third party libraries can use it to run some apply update specific initialization or bookkeeping code.
Risks
Low. This API is used only in very limited cases and by very few developers (mostly internal).
The text was updated successfully, but these errors were encountered: