[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException
michael.mudge at welchallyn.com
Mon Feb 13 16:48:51 UTC 2012
All done: https://bugzilla.xamarin.com/show_bug.cgi?id=3399
Comments are welcome.
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
>> 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
>> 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...
More information about the Mono-devel-list