[Mono] mono_thread_interruption_checkpoint

[pavelsavara]

I believe that in single-threaded browser, we don't need ability to abort thread or interrupt it.

here is list of methods which could be probably conditional on #ifndef DISABLE_THREADS making both AOT and interp smaller/faster in ST.

ABORT_PROT_BLOCK_MASK
CEE_MONO_LDPTR_INT_REQ_FLAG
EXCEPTION_CHECKPOINT
MONO_PATCH_INFO_INTERRUPTION_REQUEST_FLAG
mono_thread_clear_interruption_requested
mono_thread_clear_interruption_requested_handle
mono_thread_get_interruption_requested
mono_thread_interruption_checkpoint
mono_thread_interruption_request_flag
mono_thread_interruption_requested
mono_thread_set_interruption_requested
mono_thread_set_interruption_requested_flags
mono_thread_set_self_interruption_respect_abort_prot
mono_threads_begin_abort_protected_block

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

@BrzVlad , thoughts ?

[BrzVlad]

I think most of the code around abort protection can be removed, not just for single threaded. But it is tricky code that needs to be reviewed carefully and I'm not sure its removal can lead to decent size improvements.

[pavelsavara]

I'm not sure its removal can lead to decent size improvements.

hello world application has 500 calls to it emmited in AOT'd code.
In other words it makes every other AOT method bit larger.

The other half of the possible win is wasted CPU cycles in interp.

We could try to improve them separately, if that makes more sense.

not just for single threaded

You mean that Thread.Abort is no longer a thing in Net Core right ?

But it is tricky code that needs to be reviewed carefully

Indeed. I gave it a naive try in #112637

So far it seems there are few use-cases where this is still used.

• Maybe in Mono shutdown sequence ?
• in CMD_VM_ABORT_INVOKE in soft debugger

I'm adding few g_assert_not_reached to learn where they are called from.

[BrzVlad]

It does seem that it can lead to decent improvements.

Yes, the abort protected blocks were meant to prevent thread abort exception during finally execution, which is no longer a thing everywhere. And during shutdown, we should be free to stop threads whenever. A lot of code in this area could be removed, but it seems that we go through some of these methods when setting pending exception from native code, making it painful to remove everything altogether.

[pavelsavara]

It does seem that it can lead to decent improvements.

Do you mean size or perf ? Why this is not enough ?