[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

Miguel Mudge michael.mudge at welchallyn.com
Wed Feb 8 15:43:31 UTC 2012

On Wed, Feb 8, 2012 at 9:36 AM, Rodrigo Kumpera <kumpera at gmail.com> wrote:

> The idea is to switch away from raising the exception directly in native
> code to set the pending field and let the transition code do it.

I love this idea, and it's tremendously useful to me.  I'll see if I can
finish it.

> It looks like it's partially implemented for AMD64 only - I propose
>> stripping the related calls from exceptions-amd64.c,
>> and have mono_thread_execute_interruption
>> return mono_thread_get_and_clear_pending_exception() somewhere near the end.
> If you are willing to finish the work for amd64, it would be much welcome.

The AMD64-specific work looks like it is part of the AMD64 JIT.  I don't
have the ability to follow this model and I don't think it's necessary.  I
will instead simplify the existing partially-implemented framework, and
strip the AMD-specific code because:

> The async exception machinery needs some cleanup, I take that as granted.
> So any change must be in the direction of simplifying it and not adding
> extra complexity.

I rather go with a model where setting a pending exception and kick
> unwinding at the transition. It's safer and allow us to use stack/return
> address patching to make it
> efficient - transition must be as fast as possible since it's quite
> frequent.

No problem - emit_thread_interrupt_checkpoint emits a call
to mono_thread_interruption_checkpoint, which
calls mono_thread_interruption_checkpoint_request.  This checks the
thread->interruption flag.  I'll use this flag to indicate there is a
general pending exception (in addition to its existing purpose of
indicating there is a pending Abort/Suspend/Interrupt).  So there will be
no performance impact there.

It would be very nice if you're willing to do this work and post it on a
> public branch so we can later merge it. This can't be merged in the next
> couple month as we're stabilizing trunk to get ready for 2.12, but I doubt
> it will be ready in a shorter time than this.

I'm stuck working on the 2.10.2 branch for now.  I would be happy to post a

- Kipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120208/e497b762/attachment.html>

More information about the Mono-devel-list mailing list