Code sample

The code for the latest iteration of this design is in #7857

Summary of design

We would like to add an overall notion of "MonoClass readiness" to replace the various MonoClass:*_inited bitfields. This PR does not do that. But it adds the corresponding
change to the loading API:

typedef enum _MonoClassReady {
	/* Barebones readiness: just allocate a MonoClass and set its image, name and name space. */
	MONO_CLASS_READY_BAREBONES = 0,
	/* Instantiate readiness: metadata vtable is initialized, ready to create runtime vtables. */
	MONO_CLASS_READY_INSTANTIATE = 0xff,
	MONO_CLASS_READY_MIN = MONO_CLASS_READY_BAREBONES,
	MONO_CLASS_READY_MAX = MONO_CLASS_READY_INSTANTIATE,
} MonoClassReady;

gboolean
mono_class_init_ready (MonoClass *klass, MonoClassReady readiness);

1. We would eventually add multiple readiness levels between MIN and MAX that represent a MonoClass that is partially initialized. (I don't know precisely how many we will need, so the examples below should not be taken too seriously.) For example:

   • Some information about a class is collected from its parent. For example MonoClass:delegate is set based on the value of the parent. So we may have MONO_CLASS_READY_PARENT above MONO_CLASS_READY_BAREBONES to signal that the parent class is ready to provide that information. (This is in mono_class_setup_parent today and its protected by the loader lock and the gclass_recorded_list in the generic instance case).

   • Instance size information is currently guarded by MonoClass:size_inited. We would add a
     MONO_CLASS_READY_INSTANCE_SIZE above MONO_CLASS_READY_PARENT and below MONO_CLASS_READY_INSTANTIATE.

2. The semantics of mono_class_init_ready (klass, level) is that it is a no-op if klass is already
   ready at level level or higher, otherwise it will perform whatever initialization is needed to bring the class from its current level up to at least the requested level.

3. Eventually the various legacy initialization functions (see mono/metadata/class-init.h - e.g. mono_class_init_sizes, mono_class_layout_fields, etc) will be removed (or marked MONO_RT_EXTERNAL_ONLY) and there will be a single initialization entrypoint.

4. This only covers the "essential" fields of a MonoClass, those that directly contribute to creating a valid runtime instance of the class. Essential fields are initialized at some readiness level and are valid at that level or higher.

   For example: type_token and image are essential fields at the barebones level. delegate is an essential field at the 'parent known' level.

   We also have several "synthetic" fields, those that represent information that can be derived from the essential fields but that we choose to cache in the MonoClass for efficiency. Synthetic fields will continue to use a bit or a sentinel value (non-NULL == initialized) to guard the value. Initializing a synthetic field may require the class to be in a certain readiness level, but it is valid for a class at that level not to have the synthetic field initialized.

   For example: superclasses is a synthetic field, guarded by a non-NULL value, used for fast "is subclass of" queries that requires the parent of a class to be known, but a call to mono_class_init_read (klass, MONO_CLASS_READY_PARENT) does not cause superclasses to become initialized.

Discussion summary

(I will edit this part to collect discussion comments)

• Some of the init steps are orthogonal, so there's a lattice of readiness levels.
• we should have explicit pre-constructed and post-unloading levels to mark invalid uses - [RFC] mono_class_init_ready #7856 (comment)

TODOs

(I will edit this part to collect actionable discussion comments)

• Use BEGIN/FINAL (like coreclr) instead of MIN/MAX
• Define mono_class_init_ready and MIN and MAX readiness levels #7857 (comment) - rename INSTANTIATE for now since mono_class_init doesn't initialize the vtable today, so it's misleading.
• MonoClassReadiness instead of MonoClassReady.

The code for the current iteration of this design is in #7857