While not strictly necessary to not leak (because the process is exiting
anyway), it makes it easier to read leak reports, because these dictionaries
won't show up as leaked memory anymore.
Before:
There were 258096 MonoObjects created, 258015 MonoObjects freed, so 81 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205833 MonoObjects freed, so 1 were not freed. (static registrar)
After:
There were 258104 MonoObjects created, 258025 MonoObjects freed, so 79 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205834 MonoObjects freed, so no leaked MonoObjects. (static registrar)
* [runtime] Add support for exception marshalling to CoreCLR.
* [runtime] Add an empty implementation of the toggle ref machinery.
We need this to use the unhandled exception handler support in CoreCLR,
because the ObjectiveCMarshal.Initialize call to initialize unhandled
exception support requires passing toggle ref callbacks as well.
* [tests] The TestConstrainedGenericType test can now be re-enabled, after a few updates.
Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258054 MonoObjects created, 235172 MonoObjects freed, so 22882 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 205190 MonoObjects freed, so 614 were not freed. (static registrar)
* [runtime] Mark numerous Mono Embedding API as used only by the MonoVM bridge.
* [runtime] Exclude more unused code from the CoreCLR build.
* There's no tracing in CoreCLR, so no need to process the MONO_TRACE environment
variable (and set the trace options).
* There's no sdb debuggger, so that code can be skipped.
* The profiler support is very different, so skip that code too.
* We don't support AOT, nor aot data files, so skip that.
* [runtime] Stop generating dummy implementations of the Mono Embedding API for CoreCLR.
All of the Mono Embedding API now falls in either of these two categories:
* Only used by the MonoVM bridge.
* Has a CoreCLR implementation.
Which means that we don't need the code to generate dummy implementations for
methods that aren't in any of these two categories anymore.
* Make 'throw Objective-C exception' the default for managed exception marshalling.
* Make 'throw managed exception' the default for Objective-C exception marshalling.
* Disallow the 'unwind through native frames' option: CoreCLR won't do it.
* Disallow the 'unwind through managed frames' option: it's the safeset
option by far, and also matches the reverse case.
* Disallow the 'disable' option: this is also not safe, let's try to go the
safe route with CoreCLR.
* Change the default in native code too.
Partial fix for #10940.
Passing a 'MonoObject*' to a function that expects a GCHandle doesn't quite
work, so make sure to get a GCHandle for the exception we want to print
information about.
* Implement our xamarin_dyn_objc_msgSend[Super] overrides for ARM64.
* Modify mmp to use those overrides.
* Fix an issue with the existing xamarin_arm64_common_trampoline that caused
exceptions to not unwind correctly.
* Add an ARM64 variation of xammac tests in xharness.
* Various test fixes.
When using the MonoVM, we compare MonoClass instances by pointer. This turns
out a bit complicated for CoreCLR, because our MonoClass instances are not
unique (there can be multiple MonoClass instances that refer to the same
type), so instead implement helper methods that do the comparison. This also
has the benefit of not requiring any memory allocations on CoreCLR.
There's no general way to set a pending managed exception in CoreCLR (the
current plan is to support setting a pending managed exception for the
objc_msgSend family of functions). This means that the way we've implemented
custom wrappers that can handle Objective-C exceptions won't work, because
those wrappers currently tries to set a pending managed exception (which Mono
throws upon returning from the corresponding native wrapper function).
So rewrite this a bit: these custom wrappers now return a GCHandle with the
managed exception as an out parameter, and the calling managed code throws
that exception instead.
This also required adjusting a few API definitions to match how their wrapper
functions are defined.
* [runtime] Call into managed code to handle runtime exceptions.
This makes things easier for CoreCLR.
There should be no significant performance hits; this code path is
exceptional, and exceptions are already very heavy-weight anyways.
* Update to use xamarin_free instead of mono_free as per review.
* Port more to managed code.
This also meant reviewing calling code to make sure that MonoObject*s are
released when they should be, which meant reviewing every method that returns
a MonoObject*, and release the result.
Move the xamarin_create_managed_ref internal call to managed code, to ease things
with CoreCLR.
In order to preserve performance, this wasn't a straight forward port.
* monotouch_create_managed_ref used to detect if there already was a GCHandle for
a native object. To avoid a managed->native transition, this logic has now been
moved into the code that sets the GCHandle (the xamarinSetGCHandle🎏 / xamarin_set_gchandle_trampoline
code), and these methods return a value saying whether the GCHandle was set or
not.
* xamarin_create_gchandle will check the retain count to determine whether to create
a weak or a strong GCHandle for the managed object. In this particular case we
should never need to create a strong GCHandle, which means that we don't need to
check the retain count (saving a managed->native transition).
Using the new perftest (#11298), I get very similar numbers for both old code and new code: https://gist.github.com/rolfbjarne/e0fc2ae0f21da15062b4f051138679af (multiple runs). Sometimes the old code is faster, sometimes the new code is faster (although the old code tends to be the one who wins).
In any case there aren't any significant performance hits due to this change, so it should be good to go.
The implementation will be completely different, where the hook into CoreCLR
is in managed code.
We still need to initialize the framework_peer_release_lock mutex, so move
that code out of gc_enable_new_refcount.
* Move the existing logic to call Runtime.Initialize into the MonoVM code.
* Implement calling the managed Runtime.Initialize method from the CoreCLR bridge.
The call to Runtime.Initialize succeeds, which means we're now executing
managed code with CoreCLR for the first time.
The fields of the MonoObject struct is specific to MonoVM, so this makes sure
we don't accidentally poke into random memory on CoreCLR.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
We need to call coreclr_initialize/monovm_initialize at startup, so do that.
This is a partial implementation, in that we're not setting all the properties
that we should, and also the PINVOKE_OVERRIDE callback is not doing everything
it should either yet.
Ref: #10504.
Rolf Bjarne Kvinge
Sebastien Pouliot