1Meeting notes: Implementation idea: Exception Handling in C++/Java 2 3The 5/18/01 meeting discussed ideas for implementing exceptions in LLVM. 4We decided that the best solution requires a set of library calls provided by 5the VM, as well as an extension to the LLVM function invocation syntax. 6 7The LLVM function invocation instruction previously looks like this (ignoring 8types): 9 10 call func(arg1, arg2, arg3) 11 12The extension discussed today adds an optional "with" clause that 13associates a label with the call site. The new syntax looks like this: 14 15 call func(arg1, arg2, arg3) with funcCleanup 16 17This funcHandler always stays tightly associated with the call site (being 18encoded directly into the call opcode itself), and should be used whenever 19there is cleanup work that needs to be done for the current function if 20an exception is thrown by func (or if we are in a try block). 21 22To support this, the VM/Runtime provide the following simple library 23functions (all syntax in this document is very abstract): 24 25typedef struct { something } %frame; 26 The VM must export a "frame type", that is an opaque structure used to 27 implement different types of stack walking that may be used by various 28 language runtime libraries. We imagine that it would be typical to 29 represent a frame with a PC and frame pointer pair, although that is not 30 required. 31 32%frame getStackCurrentFrame(); 33 Get a frame object for the current function. Note that if the current 34 function was inlined into its caller, the "current" frame will belong to 35 the "caller". 36 37bool isFirstFrame(%frame f); 38 Returns true if the specified frame is the top level (first activated) frame 39 for this thread. For the main thread, this corresponds to the main() 40 function, for a spawned thread, it corresponds to the thread function. 41 42%frame getNextFrame(%frame f); 43 Return the previous frame on the stack. This function is undefined if f 44 satisfies the predicate isFirstFrame(f). 45 46Label *getFrameLabel(%frame f); 47 If a label was associated with f (as discussed below), this function returns 48 it. Otherwise, it returns a null pointer. 49 50doNonLocalBranch(Label *L); 51 At this point, it is not clear whether this should be a function or 52 intrinsic. It should probably be an intrinsic in LLVM, but we'll deal with 53 this issue later. 54 55 56Here is a motivating example that illustrates how these facilities could be 57used to implement the C++ exception model: 58 59void TestFunction(...) { 60 A a; B b; 61 foo(); // Any function call may throw 62 bar(); 63 C c; 64 65 try { 66 D d; 67 baz(); 68 } catch (int) { 69 ...int Stuff... 70 // execution continues after the try block: the exception is consumed 71 } catch (double) { 72 ...double stuff... 73 throw; // Exception is propogated 74 } 75} 76 77This function would compile to approximately the following code (heavy 78pseudo code follows): 79 80Func: 81 %a = alloca A 82 A::A(%a) // These ctors & dtors could throw, but we ignore this 83 %b = alloca B // minor detail for this example 84 B::B(%b) 85 86 call foo() with fooCleanup // An exception in foo is propogated to fooCleanup 87 call bar() with barCleanup // An exception in bar is propogated to barCleanup 88 89 %c = alloca C 90 C::C(c) 91 %d = alloca D 92 D::D(d) 93 call baz() with bazCleanup // An exception in baz is propogated to bazCleanup 94 d->~D(); 95EndTry: // This label corresponds to the end of the try block 96 c->~C() // These could also throw, these are also ignored 97 b->~B() 98 a->~A() 99 return 100 101Note that this is a very straight forward and literal translation: exactly 102what we want for zero cost (when unused) exception handling. Especially on 103platforms with many registers (ie, the IA64) setjmp/longjmp style exception 104handling is *very* impractical. Also, the "with" clauses describe the 105control flow paths explicitly so that analysis is not adversly effected. 106 107The foo/barCleanup labels are implemented as: 108 109TryCleanup: // Executed if an exception escapes the try block 110 c->~C() 111barCleanup: // Executed if an exception escapes from bar() 112 // fall through 113fooCleanup: // Executed if an exception escapes from foo() 114 b->~B() 115 a->~A() 116 Exception *E = getThreadLocalException() 117 call throw(E) // Implemented by the C++ runtime, described below 118 119Which does the work one would expect. getThreadLocalException is a function 120implemented by the C++ support library. It returns the current exception 121object for the current thread. Note that we do not attempt to recycle the 122shutdown code from before, because performance of the mainline code is 123critically important. Also, obviously fooCleanup and barCleanup may be 124merged and one of them eliminated. This just shows how the code generator 125would most likely emit code. 126 127The bazCleanup label is more interesting. Because the exception may be caught 128by the try block, we must dispatch to its handler... but it does not exist 129on the call stack (it does not have a VM Call->Label mapping installed), so 130we must dispatch statically with a goto. The bazHandler thus appears as: 131 132bazHandler: 133 d->~D(); // destruct D as it goes out of scope when entering catch clauses 134 goto TryHandler 135 136In general, TryHandler is not the same as bazHandler, because multiple 137function calls could be made from the try block. In this case, trivial 138optimization could merge the two basic blocks. TryHandler is the code 139that actually determines the type of exception, based on the Exception object 140itself. For this discussion, assume that the exception object contains *at 141least*: 142 1431. A pointer to the RTTI info for the contained object 1442. A pointer to the dtor for the contained object 1453. The contained object itself 146 147Note that it is necessary to maintain #1 & #2 in the exception object itself 148because objects without virtual function tables may be thrown (as in this 149example). Assuming this, TryHandler would look something like this: 150 151TryHandler: 152 Exception *E = getThreadLocalException(); 153 switch (E->RTTIType) { 154 case IntRTTIInfo: 155 ...int Stuff... // The action to perform from the catch block 156 break; 157 case DoubleRTTIInfo: 158 ...double Stuff... // The action to perform from the catch block 159 goto TryCleanup // This catch block rethrows the exception 160 break; // Redundant, eliminated by the optimizer 161 default: 162 goto TryCleanup // Exception not caught, rethrow 163 } 164 165 // Exception was consumed 166 if (E->dtor) 167 E->dtor(E->object) // Invoke the dtor on the object if it exists 168 goto EndTry // Continue mainline code... 169 170And that is all there is to it. 171 172The throw(E) function would then be implemented like this (which may be 173inlined into the caller through standard optimization): 174 175function throw(Exception *E) { 176 // Get the start of the stack trace... 177 %frame %f = call getStackCurrentFrame() 178 179 // Get the label information that corresponds to it 180 label * %L = call getFrameLabel(%f) 181 while (%L == 0 && !isFirstFrame(%f)) { 182 // Loop until a cleanup handler is found 183 %f = call getNextFrame(%f) 184 %L = call getFrameLabel(%f) 185 } 186 187 if (%L != 0) { 188 call setThreadLocalException(E) // Allow handlers access to this... 189 call doNonLocalBranch(%L) 190 } 191 // No handler found! 192 call BlowUp() // Ends up calling the terminate() method in use 193} 194 195That's a brief rundown of how C++ exception handling could be implemented in 196llvm. Java would be very similar, except it only uses destructors to unlock 197synchronized blocks, not to destroy data. Also, it uses two stack walks: a 198nondestructive walk that builds a stack trace, then a destructive walk that 199unwinds the stack as shown here. 200 201It would be trivial to get exception interoperability between C++ and Java. 202 203