Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[mono] Hot Reload: support for reloadable types (dotnet#66749)
Fully implement support for the `NewTypeDefinition` EnC capability: a hot reload edit can add a new type definition (class, struct, interface, enum) that contains new fields, methods, properties, events, and nested classes, and can have generic params. Also add reflection support for all of the above. This is sufficient to support hot reload of types tagged with [`CreateNewOnMetadataUpdateAttribute`](https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.createnewonmetadataupdateattribute?view=net-6.0). Contributes to dotnet#63643 and dotnet#57365 --- The implementation introduces `MonoAddedDefSkeleton` which is a bookkeeping structure that records the metadata indexes of where to find methods, fields, properties and events for a newly-added class. The issue is that normally `mono_class_create_from_typedef` expects to find all that stuff in a contiguous block starting at the row pointed by the `MONO_TYPEDEF_FIELD_LIST` or `MONO_TYPEDEF_METHOD_LIST` columns of the new typedef. But in EnC deltas, those columns are zeroed out, and instead the EnCLog functions like `ENC_FUNC_ADD_METHOD` and `ENC_FUNC_ADD_FIELD` explicitly record when a new row is added that is relevant to a particular type definition. So during the pass over the EnCLog, we start creating skeletons when we see a new row added to the typedef table. Then when we see the add functions, we record the row indices of the field, method, etc tables. As far as I can tell, the rows for a particular type definition are contiguous, so we just record the first index and the count. At the end of the pass, we save the skeletons on the metadata delta, and when code finally creates the `MonoClass` for a particular freshly-added type definition, we check the skeleton and use the recorded rows to populate the fields and methods. Event and property data is created on-demand (the demand being reflection) in basically the same way. One important note: we try very hard not to accidentally materialize a newly-added class as a `MonoClass` during the update itself - we need to at least get through the entire EnCLog - otherwise we might not see every field/method/etc and set up the class incorrectly. The upshot is that the newly-added `MonoClass` behaves like any other "normal" class - all its fields are laid out normally (they're stored in the object, not in a separate hash table). It can be generic. It can have base types, interfaces, etc. This is different from how added fields, props and events will be implemented on existing classes - we won't modify `MonoClass:fields` or the `MonoClassPropertyInfo:properties` arrays - once they have been allocated, we don't want to mess with them. Instead additions to existing classes with create `MonoClassMetadataUpdateField` (`MonoClassMetadataUpdateProperty` and `MonoClassMetadataUpdateEvent`) structs that are going to be stored on the `MonoClassMetadataUpdateInfo` that's associated with each `MonoClass`. The various iterators like `mono_class_get_fields` and `mono_class_get_props` will be modified to return the added fields/props/etc after the existing ones. This is already implemented for fields. Props and Events will be part of a separate effort to implement reflection support for them. --- * Checkpoint. Infrastructure for added types * register member->parent lookups for newly-added classes and members * fix off by one error creating class from skeleton * AddNestedClass test works with mono now; also make it generic * checkpoint: adding properties it "works" but only because we don't look very hard for the new properties anywhere. reflection is probably pretty broken. * Add a property to AddNestedClass test * remove allow class/field/method/property ifdefs keep the instance field ifdef for now * add event to AddNestedClass * add DISALLOW_BROKEN_PARENT ifdef allow CustomAttribute row modifications to change Parent, while dotnet/roslyn#60125 is being sorted out * checkpoint: adding events * Add new test ReflectionAddNewType * Add new types to the image name cache * Assembly.GetTypes and additional tests * Make nested types work * GetInterfaces on new types; also Activator.CreateInstance * Mark mono_class_get_nested_classes_property as a component API also mono_class_set_nested_classes_property * Add GetMethods, GetFields, GetMethod, GetField test * [class] Implement added method iteration Change the iterator from storing MonoMethod** values to storing an iteration count. For added methods, when the iteration count is more than mono_class_get_method_count, run through the hot reload added_members list and iterate over any relevant methods * Implement added field iteration * Add a GetField(BindingFlags.Static) test case * Add Enum.GetNames and GetProperties tests - not working yet * Mark mono_class_get_method_count as a component API also mono_class_get_field_count * Enum values work * Use GSList for added_fields (and props, events); add from_update bit Use GSList to simplify the concurrency story for accessing added_fields (and added_props and added_events, eventually): unlike a GPtrArray it won't resize, so we don't need to lock readers. Add a from_update bit to MonoProperty and MonoEvent - when props or events are added to existing classes, they will have the bit set. That means that pointer arithmetic to figure out the prop (or event) tokens won't be usable (since they're not allocated in one big block). * Reflection on props in new classes works * events on new classes work * Add CustomAttribute reflection test * remove test for props on existing type - it's not part of this PR * instance field additions to existing types aren't supported yet * rm TODO and FIXME * store prop and event from_update bit in attrs The upper 16 bits aren't used for ECMA flags, so grab a bit for metadata-update * remove instance fields from reflection test since Mono doesn't support them yet * make the Browser EAT lanes happy Add some fields to the baseline versions of some test assemblies to keep some types that are used in the deltas from getting trimmed away
- Loading branch information