another approach to exceptions?

Sun Feb 29 14:27:00 GMT 2004

It seems to me that gcj could benefit from a third EH personality with
a different portability/size/speed tradeoff than sjlj (great
portability, awful performance, awful size), and dwarf2 (awful
portability, awful size, great performance).
The following strategy might have to assume that only Java code can
throw/catch exceptions. It also probably screws up stack traces,
although I think (with a lot of work) we could get them back (without
line number info).
What if gcj interpreted this code:
 void foo() {
 int a = 5;
 try {
 blah(a);
 } catch {
 // ...
 }
 }
as this:
 void foo() {
 int a = 5;
 void bar() {
 blah(a);
 }
 bar();
 return;
 HANDLER: {
 // ...
 }
 }
using the "nested functions" non-ANSI-C construct that gcc allows? 
You could then throw an exception by saving the stack return address
in a thread-local, overwriting the return address on the stack with an
invalid value (0x01) and returning the exception as the return value.
The SEGV handler would then get triggered and could change the return
address to HANDLER and "continue returning".
Does this work in real life?
 - a
-- 
"It's lucky," he added, after a pause, "that there are such a lot of
islands in the world. I almost envy you, Mr. Watson."
 -- Mustapha Mond