dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Safely implementing Thread.Abort


From: Rhys Weatherley
Subject: Re: [DotGNU]Safely implementing Thread.Abort
Date: Thu, 20 May 2004 13:54:11 +1000
User-agent: KMail/1.4.3

On Thursday 20 May 2004 12:18 pm, Russell Stuart wrote:

> This will always work, but you have generate equivalent
> code for the JIT.  Will you be able to bring yourself
> to do that?  It won't be just an instruction or two.
> The "tst" op-code will overwrite the CPU's condition
> flags, which will have to be restored if you are
> doing a conditional backward jump.  In any decently
> optimised code most of them are conditional.

The JIT case is easy.  It can be done with signals: send a signal to the 
thread and just throw from within the handler (which Mono does BTW).  It will 
unwind the stack and just deal with it.  The CVM interpreter doesn't use 
stack unwinding for exception throws because it maintains its own stack 
separate from the system one (a design oversight that I'm fixing in libjit's 
builtin interpreter).

Even if an explicit check is needed in the JIT, it can be done *before* the 
argument values are loaded for the branch comparison, so that the condition 
codes don't need to be saved or restored.  The JIT can push the check back 
through the block quite a bit, since it cannot side-effect any of the 
variables in the block.

There's no law that says that it has to be checked at the bottom of the loop. 
It can be placed at the loop head instead (loop heads are any labels that are 
the destination of a backwards jump).  The same applies for CVM.

Anyway, what I am trying to get you two to do is the following:

1. Make something, anything, work!  As long as it is simple.
2. Profile it and compare against the original before optimizing.
3. Don't change the method cache.  The method cache is read-only on purpose.

If worst comes to worst, it isn't impossible to add a "--disable-aborts" 
option to "ilrun" that removes the overhead for people who don't want it.

Cheers,

Rhys.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]