[NativeAOT] Objective-C Marshal: object tracker support

[AustinWise]

With these changes the src/tests/Interop/ObjectiveC/ObjectiveCMarshalAPI/ test passes everything except _Validate_ExceptionPropagation.

The native part ( interoplibinterface.h and interoplibinterface_objc.cpp ) are based off the corresponding files from CoreCLR. Potentially parts could be shared between both runtimes, but it's not a lot of code.

Compared CoreCLR version, every Objective-C object takes 3x the GC handles. In addition the ref-counted GC handle, there is a dependent handle in the conditional weak table and a long weak handle to extend the lifetime ObjcTrackingInformation. If that is not acceptable, the tracking information could be moved into the SyncBlock like CoreCLR does. With the current implementation of NativeAOT sync blocks, that would reduce handle overhead to 2x that of CoreCLR, at the cost of making every macOS sync block bigger.

Related issue: #77472

[jkotas]

cc @AaronRobinsonMSFT

[filipnavara]

If that is not acceptable, the tracking information could be moved into the SyncBlock like CoreCLR does.

It would likely be possible to limit the overhead only to types that are marked with the ObjectiveCTrackedTypeAttribute at expense of making the SyncTable entry allocation/references more complex. I played with the idea but it very quickly became unwieldy.

[AustinWise]

I added some comments on things I'm not sure about.

[AustinWise]

I updated the PR to change the way callbacks work. There are a couple of outstanding items (listed in the PR description) that I need to address before this can be merged.

[AustinWise]

I addressed known issues with this PR (making it compatible with multiple class libs). This PR is now ready for further review.

[MichalStrehovsky]

The compiler side looks good to me, the CoreLib interaction too, but I can't speak to the GC interaction details or objc interop in general. Cc @VSadov as well

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

With these changes the src/tests/Interop/ObjectiveC/ObjectiveCMarshalAPI/ test passes everything except _Validate_ExceptionPropagation.

The native part ( interoplibinterface.h and interoplibinterface_objc.cpp ) are based off the corresponding files from CoreCLR. Potentially parts could be shared between both runtimes, but it's not a lot of code.

Compared CoreCLR version, every Objective-C object takes 3x the GC handles. In addition the ref-counted GC handle, there is a dependent handle in the conditional weak table and a long weak handle to extend the lifetime ObjcTrackingInformation. If that is not acceptable, the tracking information could be moved into the SyncBlock like CoreCLR does. With the current implementation of NativeAOT sync blocks, that would reduce handle overhead to 2x that of CoreCLR, at the cost of making every macOS sync block bigger.

Related issue: #77472

Author:	AustinWise
Assignees:	-
Labels:	area-Interop-coreclr, community-contribution, area-NativeAOT-coreclr
Milestone:	-

[AaronRobinsonMSFT]

FYI @rolfbjarne

[rolfbjarne]

Does the NativeAOT GC run collections on multiple threads (like the server GC), or only on a single thread (like the workstation GC)?

[AustinWise]

Does the NativeAOT GC run collections on multiple threads (like the server GC), or only on a single thread (like the workstation GC)?

According to this comment from the Xamarin repository, the Server GC is not supported:

https://github.com/xamarin/xamarin-macios/blob/main/runtime/coreclr-bridge.m#L203-L210

[jkotas]

Does the NativeAOT GC run collections on multiple threads (like the server GC), or only on a single thread (like the workstation GC)?

Native AOT respects the same build configuration settings as standard CoreCLR. It uses workstation GC by default and server GC can be enabled by setting <ServerGarbageCollection>true</ServerGarbageCollection> in the project file.

According to this comment from the Xamarin repository, the Server GC is not supported

What happens if somebody enables server GC in a project that uses Xamarin interop? Does it just crash silently, or does it produce descriptive error somewhere?

[rolfbjarne]

Does the NativeAOT GC run collections on multiple threads (like the server GC), or only on a single thread (like the workstation GC)?

According to this comment from the Xamarin repository, the Server GC is not supported:

xamarin/xamarin-macios@main/runtime/coreclr-bridge.m#L203-L210

That's exactly why I'm asking 😄

Does the NativeAOT GC run collections on multiple threads (like the server GC), or only on a single thread (like the workstation GC)?

Native AOT respects the same build configuration settings as standard CoreCLR. It uses workstation GC by default and server GC can be enabled by setting <ServerGarbageCollection>true</ServerGarbageCollection> in the project file.

According to this comment from the Xamarin repository, the Server GC is not supported

What happens if somebody enables server GC in a project that uses Xamarin interop? Does it just crash silently, or does it produce descriptive error somewhere?

I intended to make it an error, but it seems I never did that. I've filed an issue so I don't forget again: dotnet/macios#16853

[AaronRobinsonMSFT]

From the interop side of things, I am fine with this. I'd like to make sure @MichalStrehovsky is okay from the NativeAOT side and @rolfbjarne is aware and okay with support from the Xamarin side.

Thanks!

[AustinWise]

@AaronRobinsonMSFT Regarding your suggestions to change the type parameters on the unmanned function pointers from IntPtr to void*, these don't match the public the definitions on the public API ObjectiveCMarshal.Initialize. So compilation failed. When I tried updating the public API to use void*, I got the following error:

error CP0002: Member 'System.Runtime.InteropServices.ObjectiveC.ObjectiveCMarshal.Initialize(delegate* unmanaged, delegate* unmanaged<nint, int>, delegate* unmanaged<nint, void>, System.Runtime.InteropServices.ObjectiveC.ObjectiveCMarshal.UnhandledExceptionPropagationHandler)' exists on ref/net7.0/System.Private.CoreLib.dll but not on lib/net7.0/System.Private.CoreLib.dll

So I'm going to stick to using IntPtr for consistency with the public API.

[AaronRobinsonMSFT]

So I'm going to stick to using IntPtr for consistency with the public API.

Ah. Okay. I missed that. We try to use void* now when possible since IntPtr degrades to nint and is sort of misleading in the majority of cases. If this isn't possible then please ignore.

[MichalStrehovsky]

Compiler side still looks good. I can't judge GC interactions or objc semantics - not reviewing that.

[rolfbjarne]

LGTM

[jkotas]

Thank you!