-
Notifications
You must be signed in to change notification settings - Fork 509
Add support for eager static constructors #889
Conversation
@@ -18,6 +20,7 @@ internal static class StartupCodeHelpers | |||
internal static void Initialize() | |||
{ | |||
InitializeStringTable(); | |||
RunEagerClassConstructors(); | |||
RuntimeImports.RhEnableShutdownFinalization(0xffffffffu); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will be able to get rid of the RhEnableShutdownFinalization line and switch to the Project N plan (this will be triggered from the eager cctor of the Environment class).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We got rid of the shutdown finalization for .NET Core (https://github.com/dotnet/corefx/issues/5205 has the long story), so it would be more appropriate to delete the RhEnableShutdownFinalization
here and keep the CORERT ifdef in Environment.cs as a reminder to clean it up for UWP as well.
The shutdown finalization as implemented in Redhawk runtime does not really work because of it does not suspend foreground threads like in full .NET. We never noticed because of UWP apps do not ever shutdown, and small unit tests do not highlight the problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! I'll send another pull request to delete it. I don't want to convolute this one with unrelated things.
dcb6997
to
0dcf685
Compare
This looks like a lot of code just to support a rarely used feature, but a lot of this is plumbing that will let me delete some existing code in a subsequent commit. Some of this will also be needed to support the various preinitialized data attributes/general type preinitialization. * Redirecting uses of HasStaticConstructor to go through the TypeInitialization class (exposing higher level APIs "HasLazyCctor" and "HasEagerCctor") * Emitting a new table with an array of eager class constructors * Augmenting GC/nonGC/ThreadStatic and Method nodes to depend on an entry in the eager cctor table if the owning type has a cctor * Startup code addition to iterate over the list of eager cctors and call them one by one Reusable code: * ArrayOfEmbeddedPointers: we have a buch of places where we just want an array of pointers. This will let us e.g. delete StringIndirectionNode. Missing features: ordering the eager cctors. I want to think a bit about how we parse custom attribute blobs before I implement that. Fixes dotnet#471.
0dcf685
to
f97d248
Compare
It also needs some thinking about how it should actually work without global view/analysis... |
LGTM |
Add support for eager static constructors
Shutdown finalization was abandoned for .NET core. See discussion in pull request dotnet#889 and dotnet/corefx#5205.
Shutdown finalization was abandoned for .NET core. See discussion in pull request dotnet#889 and dotnet/corefx#5205.
This looks like a lot of code just to support a rarely used feature,
but a lot of this is plumbing that will let me delete some existing code
in a subsequent commit. Some of this will also be needed to support
the various preinitialized data attributes/general type preinitialization.
Reusable code:
Missing features: ordering the eager cctors. I want to think a bit about
how we parse custom attribute blobs before I implement that.
Fixes #471.