[mono] Hot Reload: support for reloadable types #66749

lambdageek · 2022-03-17T02:21:01Z

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.

Contributes to #63643 and #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.

This reverts commit 51ebd8d77d3d8e8a0e04bfba641134448e3c1813.

it "works" but only because we don't look very hard for the new properties anywhere. reflection is probably pretty broken.

keep the instance field ifdef for now

allow CustomAttribute row modifications to change Parent, while dotnet/roslyn#60125 is being sorted out

also mono_class_set_nested_classes_property

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

also mono_class_get_field_count

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).

The upper 16 bits aren't used for ECMA flags, so grab a bit for metadata-update

since Mono doesn't support them yet

lambdageek · 2022-03-17T13:42:37Z

/azp run runtime-extra-platforms

azure-pipelines · 2022-03-17T13:43:28Z