[mono] Base ALC unloadability functionality

[CoffeeFlux]

Various functionality is behind build defines due to both stability and performance concerns.

Remaining work for this PR:

• Scan RefTracker from objects
• Scan RefTracker from stack walk
• Get inflated method properly in mono_memory_manager_from_method
• Rebase

Remaining long-term work:

• Add and populate keepalive field with RefTracker for reflection types
• Update remaining code memory allocations (mostly JIT and AOT)
• Put MemoryManager/RefTracker pointers directly in vtables
• Update docs
• Add MONO_ROOT_SOURCE_MEMORY_MANAGER (or something like that)
• Add exclusions for creating certain types within collectible ALCs
• Turn on by default for netcore

[ghost]

Tagging subscribers to this area: @CoffeeFlux
Notify danmosemsft if you want to be subscribed.

[lambdageek]

I'd err on the side of being paranoid about locking, for now, during unloading.

Overall this seems like it will work, but I think for generic instance objects we'll need a GenericRefTracker managed object that references the set of ReferenceTrackers the instance could come from.

[lambdageek]

You will need to pass some kind of user_data to handle_ref_trackers_from_frame so that it call call (GcScanFunc)ctx.ops->copy_or_mark_object (see how mono_handle_stack_scan does it, below) during the precise pass.

[lambdageek]

It's supposed to scan the obj->vtable->klass->image->alc->ref_tracker gc handle for a non-generic object and
for a generic instance it's each_ref_tracker_of_image_set (((MonoClassGenericInst*)obj->vtable->klass)->generic_class->owner) something like that?

So if we put something in the vtable directly, for a generic instance we'd need some kind of GenericRefTracker that points at an array of regular ref trackers, right?

[vargaz]

What does the _code suffix mean here ?

[CoffeeFlux]

Just that it's code memory, though maybe that's unnecessary. I wasn't sure on the nomenclature for a bunch of this.

[vargaz]

Would be nice to split parts of this into smaller PRs, its huge.

[CoffeeFlux]

Yeah, I'll push the next round of changes and then start chunking it up into separate PRs. Some of the commits should already be reasonably-sized at least.

[srxqds]

excited work，why not this pr merged first?

[CoffeeFlux]

I'm currently on vacation, so I wouldn't expect this PR to move a whole lot right now :)

[srxqds]

when can this pr be merged?
and when continue to begin the remain work?
I think I should make it myself because our project can not waiting for the complete work.
if this pr merge what job should we do to make alc supported unloading assembly?

[srxqds]

?

[CoffeeFlux]

I'll be working on this more next week. It will not be part of the .NET 5 release; that has already branched without this PR, and master is now .NET 6.

[srxqds]

OK， thank for your reply, if this feature work, we will begin with .net6.
is there release date of .net6 preview1?