[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
patch.
- 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