[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Miguel Mudge]

All done:  https://bugzilla.xamarin.com/show_bug.cgi?id=3399

Comments are welcome.

- Kipp

On Mon, Feb 13, 2012 at 10:51 AM, Rodrigo Kumpera <kumpera at gmail.com> wrote:

>
>
> 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/be0f8d5b/attachment.html>