[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Rodrigo Kumpera]

On Wed, Feb 8, 2012 at 1:43 PM, Miguel Mudge
<michael.mudge at welchallyn.com>wrote:

> 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.
>
>
Nice, keep us posted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120213/899500e9/attachment.html>