[mono][eventpipe] Implementing MethodDetails and BulkType events

[mdh1418]

This PR looks to implement MethodDetails and BulkType trace events on mono, closely following the implementation of src/coreclr/vm/eventtrace.cpp's SendMethodDetailsEvent and FireBulkTypeEvent. In doing so, apps running on mono can be traced following steps from https://github.com/dotnet/runtime/blob/main/docs/design/mono/diagnostics-tracing.md and produce a .nettrace file with relevant MethodDetails and BulkType events. This .nettrace containing MethodDetails and BulkType events is necessary to leverage the dotnet-pgo tool to generate a corresponding .mibc file for future consumption in the mono AOT compiler.

This PR makes the following changes:

• Implements MethodDetails events in ep_rt_mono_send_method_details_event (2nd commit)
• Implements BulkType events in ep_rt_mono_fire_bulk_type_event (4th commit)
• Extends LttngDataTypeMapping to have a mono friendly mapping (1st commit)
• Utilizes mono method signature getter to avoid accessing method signatures prior to creation (3rd commit)

---

Creating a .mibc on mono from the HelloWorld sample

1. Building mono+libs
2. Building the HelloWorld sample with make run
3. Generating a trace
   3a. DOTNET_DiagnosticPorts="/Users/mdhwang/myport,suspend" <path to app executable>
   3b. dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:0x1F000080018:5 --diagnostic-port ~/myport
4. dotnet-pgo create-mibc --trace <path-to-trace> (built with a dotnet-pgo tool with AddAssembliesAssociatedWithType modified to skip generic parameters)

if (type.IsGenericParameter)
  return;

Modification no longer needed.

---

Implementation Details

For the most part, the implementation of the relevant functions are similar to CoreCLR. Below are some key differences

ep_rt_mono_send_method_details_event

Utilizes a helper get_typeid_for_type in order to obtain a unique type ID, to fulfill the niche of CoreCLR's type handle

ep_rt_mono_log_type_and_parameters_if_necessary

Decided to not implement the hash table until it will actually be used, which seems to be when ep_rt_mono_log_type_and_parameters_if_necessary is used outside of ep_rt_mono_send_method_details_event

ep_rt_mono_log_type_and_parameters

In line with LogTypeAndParameters except for the absence of typeLogBehavior, for currently this is only called following ep_rt_mono_send_method_details_event which always logs.

ep_rt_mono_log_single_type

Fills in rg_type_parameters and c_type_parameters by three categories of MonoType 1) MONO_TYPE_ARRAY MONO_TYPE_SZARRAY 2) MONO_TYPE_GENERICINST 3)MONO_TYPE_CLASS MONO_TYPE_VALUETYPE MONO_TYPE_PTR MONO_TYPE_BYREF for any embedded type parameters. Does not sets_nameand keeps it asNULL` until the data will actually be used in mono, which GC Heap Dumps are a likely candidate for.

ep_rt_mono_fire_bulk_type_event

Copies to the BulkTypeEvent buffer through helper functions.

Various helper functions and static const variables have been added in addition to BulkTypeValue and BulkTypeEventLogger structs with respective memory management init/fini/clear functions.

---

TODO/Questions

Does sName in eventtrace.cpp need to be carried over?
We have opted to keep s_name as NULL until it is actually used in mono, which GC Heap Dumps are a likely candidate for.

Variable size array for rg_type_parameters in BulkTypeValue struct that already has variable size field s_name
Figured out that StackSArray<ULONGLONG> has a fixed size that evaluates to 32

Where else to emit ep_rt_mono_send_method_details_event?

How necessary are the 0x06 method token mask and 0x02 type token masks, should dotnet-pgo be tweaked instead?
Found the equivalent for mono using mono_metadata_make_token and mono_metadata_token_index

How to implement if_necessary portion of LogTypeAndParametersIfNecessary (th.IsRestored and what exactly is client usage of LogTypeAndParametersIfNecessary)
Decided to not implement the hash table until it will actually be used, which seems to be when ep_rt_mono_log_type_and_parameters_if_necessary is used outside of ep_rt_mono_send_method_details_event

[lambdageek]

Good start. Could be a little bit less copy-pasty.

The biggest issue is the use of m_class_is_byreflike when you mean to look at MonoType:byref.

Also I'm concerned about locking and generally accessing the bulk types buffer from multiple threads. If multiple threads are writing and any one of them could fire the buffer, there's no guarantee that the other threads finished populating their entry.

I would suggest using a simple mutex to only allow one function to access the buffers at a time (basically make ep_rt_mono_log_type_and_parameters take a mutex),

[lambdageek]

It's coming together

The main remaining question is around the memory management of s_name.

Also some nits about intptr_t (it's by definition either 8 or 4 bytes, depending on the architecture. so it's not a great idea to use it as a wire format type)

[lambdageek]

Mono bits LGTM. @josalem or @lateralusX any other issues in the generator scripts or in ep-rt-mono that you think need to be addressed in this PR?

[lateralusX]

Overall it looks good, nice work! A couple of smaller things noted. I also think you should do a pass and drop all the variable prefixes used (p_, s_ m_ rg_ etc), its not Mono code style using that, and I assume you pretty much took variable names from CoreCLR C++ implementation and used them in this PR.

[lambdageek]

small quality of life suggestion

[mdh1418]

Looks like all the default lanes built successfully (except a Browser wasm windows lane on runtime-staging that timed out after 3 hrs).

Looking at how using lttngDataTypeMapping on both mono + coreclr works for all platforms through CI as it appeared to work fine on OSX mono/coreclr. Looks like atleast ep_char8_t is problematic for coreclr, so keeping the mappings separate for mono and coreclr.

@josalem could I get another 👀 at this PR, looking to merge as soon as we can

[mdh1418]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[josalem]

👍 LGTM

[mdh1418]

The failures look unrelated to this PR

[mdh1418]

Thanks @lambdageek @lateralusX @josalem for all of your help!