stack questions

  • Thread starter Thread starter DC
  • Start date Start date
D

DC

Hi all,

First of all, let me asure you you will not be doing my homework for me if
you are good enough to reply - I have been a professional programmer for a
couple of years now, I just never studied Computer Science so I like to try
and 'catch up' on stuff like this at the weekend.

Having said that I have a couple of questions around the excution stack, in
particular 2 things are bothing me:

1. It is said that on encountering an exception, the execution engine
"unwinds" the call stack looking for a suitable exception handler. In the
example below can we assume that the address of the error handling code is
pushed onto the stack as the return address before executing the try block
and that, infact, the code within the try block is in itself executed as a
function call within it's own stack frame? This can't be the answer though
as the catch block only executes where the stack is unwinding 'in error' not
simply in unwinding during normal flow. So what is really going on??

try
{
//some work
}
catch
{
//handling code
}

2. Continuations in C# - are they really unwinding and rewinding the stack -
or is there some sort of complirer magic going on that creates an invisible
state machine?


Love to know your thoughts on the above.
Cheers
 
I don't know exactly how Microsoft implements the throw/catch logic, but a
classical way to do it is to save the value of the registers just before the
try block and to implement throw by restoring the registers.

In C, this can be done with setjmp and longjmp. See
http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.shtml for details.

Bruno

Of course, you need some logic to chain the areas where you save the
registers, so that the throw can find the last
 
DC said:
First of all, let me asure you you will not be doing my homework for me if
you are good enough to reply - I have been a professional programmer for a
couple of years now, I just never studied Computer Science so I like to try
and 'catch up' on stuff like this at the weekend.

Having said that I have a couple of questions around the excution stack, in
particular 2 things are bothing me:

1. It is said that on encountering an exception, the execution engine
"unwinds" the call stack looking for a suitable exception handler. In the
example below can we assume that the address of the error handling code is
pushed onto the stack as the return address before executing the try block
and that, infact, the code within the try block is in itself executed as a
function call within it's own stack frame? This can't be the answer though
as the catch block only executes where the stack is unwinding 'in error' not
simply in unwinding during normal flow. So what is really going on??
Click to expand...

I believe that when the exception is thrown, the JIT knows about
exception handlers within each stack frame - it doesn't necessarily
need to unwind the stack, as you've pointed out. The basic principle is
that execution jumps to the innermost exception handler which is
capable of handling that exception type.
2. Continuations in C# - are they really unwinding and rewinding the stack -
or is there some sort of complirer magic going on that creates an invisible
state machine?
Click to expand...

I assume you mean the "yield" statement? It's creating a state machine.
If you decompile the generated code, it can be very interesting to look
through.
 
Jon Skeet said:
I believe that when the exception is thrown, the JIT knows about
exception handlers within each stack frame - it doesn't necessarily
need to unwind the stack, as you've pointed out. The basic principle is
that execution jumps to the innermost exception handler which is
capable of handling that exception type.


I assume you mean the "yield" statement? It's creating a state machine.
If you decompile the generated code, it can be very interesting to look
through.
Click to expand...
 
My thanks to both who replied.

Jon Skeet said:
I believe that when the exception is thrown, the JIT knows about
exception handlers within each stack frame - it doesn't necessarily
need to unwind the stack, as you've pointed out. The basic principle is
that execution jumps to the innermost exception handler which is
capable of handling that exception type.


I assume you mean the "yield" statement? It's creating a state machine.
If you decompile the generated code, it can be very interesting to look
through.
Click to expand...
 
| Hi all,
|
| First of all, let me asure you you will not be doing my homework for me if
| you are good enough to reply - I have been a professional programmer for a
| couple of years now, I just never studied Computer Science so I like to
try
| and 'catch up' on stuff like this at the weekend.
|
| Having said that I have a couple of questions around the excution stack,
in
| particular 2 things are bothing me:
|
| 1. It is said that on encountering an exception, the execution engine
| "unwinds" the call stack looking for a suitable exception handler. In the
| example below can we assume that the address of the error handling code is
| pushed onto the stack as the return address before executing the try block
| and that, infact, the code within the try block is in itself executed as a
| function call within it's own stack frame? This can't be the answer though
| as the catch block only executes where the stack is unwinding 'in error'
not
| simply in unwinding during normal flow. So what is really going on??
|
| try
| {
| //some work
| }
| catch
| {
| //handling code
| }
|
A two phase exception handling model is employed by the CLR, and CLR
exceptions are implemented on top of the Windows SEH mechanism (as are the
C++ exceptions).
When an exception is thrown, the CLR initiates the first phase which consist
of a stack walk to search for an appropriate exception handler (the one
who's filter is able to deal with the exception!), in the second phase the
stack is unwound until the frame containing the handler is reached. Note
that unwinding the stack, causes the finally blocks on the unwounded frames
to be executed.
More gory detail, can be found here:
http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx



Willy.
 
Back
Top