From: "Patrick R. Michaud" <[email protected]>
Date: Fri, 18 Dec 2009 15:58:21 -0600
For the past couple of weeks, chromatic and I have been exploring
various mechanisms to create a single ExceptionHandler instance for a
Sub that can be shared across multiple invocations of that Sub . . .
[examples omitted]
I'm guessing that when the return exception is thrown, the
ExceptionHandler is invoked and returns to the context in which it
was created (skipping all of the intermediate contexts that attempted
to (re)use the ExceptionHandler object). Thus we recurse 27 times,
throw a return exception with a value of 1, that jumps back to the
first invocation of fib(), and 1 gets returned as our result.
Yes. The problem is that "fib" is recursive, so must have multiple
active invocations, each of which needs a separate active handler.
FWIW, for non-recursive functions, this approach ought to work if the
set_addr were done unconditionally:
$P15 = get_global 'fib_eh'
unless null $P15 goto have_fib_eh
new $P15, 'ExceptionHandler'
$P15."handle_types"(58)
set_global 'fib_eh', $P15
have_fib_eh:
set_addr $P15, control_14
push_eh $P15
However, this code returns the same answer when it ought to get stuck in
an unbounded loop, always returning to the *last* invocation. I am
guessing that this is because set_addr has changed since I last looked;
I can't see where the return context is established.
But in any case, to apply this optimization, the compiler would have
to prove that the sub could never have multiple simultaneously active
invocations. This would be difficult at best for a dynamic language,
and a complete nonstarter in the presence of coroutines.
Sorry for not delivering the bad news sooner, but this line of
reasoning didn't occur to me until I read your analysis.
-- Bob Rogers
http://www.rgrjr.com/
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
