Objective-C interop design

[AaronRobinsonMSFT]

Design document for how .NET can enable Objective-C across multiple .NET runtime implementations.

The design here is represented in the API proposal found at dotnet/runtime#44659.

This design was originally posted at dotnet/runtime#44934.

[AaronRobinsonMSFT]

/cc @jkotas @jkoritzinsky @elinor-fung @rolfbjarne @marek-safar @jeffschwMSFT

[filipnavara]

I recently found out that Xamarin also uses Mono profiling API to automatically inject NSAutoreleasePool in every managed thread. Apparently that's covering for a difference between the behaviour of NSThread APIs and the POSIX threads. Is that something that should also be cover by this document or not?

[AaronRobinsonMSFT]

@filipnavara That is definitely related in some ways. That work was integrated into the main branch via dotnet/runtime#47592. I suppose I can add those details here.

[filipnavara]

@AaronRobinsonMSFT That's related but not identical issue. The thread pool needs an explicit autorelease pool that is drained around each work item. What Xamarin does is to setup autorelease pool for every managed thread which is still not implemented on the CoreCLR port.

[AaronRobinsonMSFT]

What Xamarin does is to setup autorelease pool for every managed thread which is still not implemented on the CoreCLR port.

Right, we are only supporting this via the threadpool workitem at least that was my understanding of the plan. The integration with every managed thread hasn't been discussed or considered to my knowledge.

[filipnavara]

The integration with every managed thread hasn't been discussed or considered to my knowledge.

It's my understanding as well that it was not discussed which is why I am bringing it up. :-) It would be a breaking change with quite a lot of consequences not to create the autorelease pool. At very least I would expect it to be documented so the users who encounter the issue know that they have to insert it explicitly. That may not be always possible when consuming 3rd-party libraries that create their own threads though.

[AaronRobinsonMSFT]

It would be a breaking change with quite a lot of consequences not to create the autorelease pool.

@rolfbjarne or @kouvel May be able to help shed some light on this nuance.

[kouvel]

It was my understanding that there would need to be an autorelease pool for every thread that may run managed code, including finalizer thread, tiering background thread, multi-core JIT background thread, etc.

[kouvel]

For externally created threads that enter the runtime to run managed code, I'm not sure if an autorelease pool is needed. May depend on how the thread was created, guess it wouldn't hurt to have a pool for that case too.

[rolfbjarne]

What Xamarin does is to setup autorelease pool for every managed thread which is still not implemented on the CoreCLR port.

Right, we are only supporting this via the threadpool workitem at least that was my understanding of the plan. The integration with every managed thread hasn't been discussed or considered to my knowledge.

It was discussed at some point, but I forget where and when and with whom.

It was my understanding that there would need to be an autorelease pool for every thread that may run managed code, including finalizer thread, tiering background thread, multi-core JIT background thread, etc.

Correct.

For externally created threads that enter the runtime to run managed code, I'm not sure if an autorelease pool is needed. May depend on how the thread was created, guess it wouldn't hurt to have a pool for that case too.

I'm not sure either, but it won't hurt to have the pool for this case too (at the very least it's theoretically possible to need it).

Should I file a new issue for this, or should it be incorporated into this issue?

[lambdageek]

I'm not sure either, but it won't hurt to have the pool for this case too (at the very least it's theoretically possible to need it).

I need to trace through the profiler API to see if the event that xamarin-macios subscribes to is raised for external threads that attach to the runtime. I suspect we do not.

I agree that it seems like one could come up with an example where it is necessary.

[AaronRobinsonMSFT]

@rolfbjarne I think creating one for every managed thread is relatively easy to accomplish, but there is the question of when to drain that pool. Is this something we need to handle in the runtime or is that handled somewhere else? I didn't see the case in xamarin-macios where the NSAutoreleasePool is drained other than when the thread is terminated. Want to confirm my understanding here.

[rolfbjarne]

@rolfbjarne I think creating one for every managed thread is relatively easy to accomplish, but there is the question of when to drain that pool. Is this something we need to handle in the runtime or is that handled somewhere else? I didn't see the case in xamarin-macios where the NSAutoreleasePool is drained other than when the thread is terminated. Want to confirm my understanding here.

The pool should be drained when the thread terminates, it spans the entire lifetime of the thread.

[lambdageek]

I'm not sure either, but it won't hurt to have the pool for this case too (at the very least it's theoretically possible to need it).

I need to trace through the profiler API to see if the event that xamarin-macios subscribes to is raised for external threads that attach to the runtime. I suspect we do not.

Mono raises the thread_started event from fire_attach_profiler_events

https://github.com/dotnet/runtime/blob/94d41d70d7038d94149d485a0f153eb8012859b3/src/mono/mono/metadata/threads.c#L1093

fire_attach_profiler_events is called when new threads are created, and also from the thread attach machinery when a foreign thread attaches to the runtime.

[AaronRobinsonMSFT]

@lambdageek Thanks for the confirmation. I will update the prototype with that logic.

[AaronRobinsonMSFT]

@rolfbjarne @lambdageek @jkoritzinsky @elinor-fung Please take a look at this design and ensure it aligns with your understanding of our Objective-C interop story.